Re: [TLS] Please discuss: draft-housley-evidence-extns-00

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

"Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx> writes:

> Eric,
>
> I meant to say the rule is this: whatever app data you send, you MUST chase
> it with EvidenceRequest.  So with this rule, server MUST expect
> EvidenceRequest-1 to be paired with ApplicationData-1.  This rule is in
> effect for the entire TLS session including any resumes.

1. I don't understand what you mean by "whatever app data you send".
   Do you mean after any application write to TLS? Any record?
   Recall that TLS is a stream protocol. In the former case,
   how does the receiver enforce this rule? In the latter
   case, you're signing every record.
2. It seems to me that you've just required that every single TLS
   record (or at least short runs of records) be signed (plus
   a second signature by the receiver). Have
   you considered the performance and bandwidth issues associated
   here?


> If app needs to store them, app
> still doesn't need to be aware of the protocol rules.  As far as the app is
> concerned, there's either app data (and Evidence- if it wants to fetch it)
> or there isn't.  IF the TLS Evidence rules required that the TLS session be
> shut down, then app will discover that the session is terminated on next
> read or write attempt.

I don't understand what this means.


>> If the server wants to follow the (reasonable) policy of not
>> performing any actions until after he's received signed instructions
>> from the client, then he has to block waiting for the client to
>> generate a signature. At minimum this requires interaction with the app
>> because (again) the TLS stack doesn't know. Moreover, without
>> some external agreement about how often these are generated,
>> you can get a deadlock. Now, the server could certainly ask for
>> a signature by sending his own Evidence-Request, but now you're
>> requiring app interaction.
>
> I think there's ways to address this challenge.  My solution is ok not
> great.  Have the TLS server hold on to the last app data TLS record until
> another app data or an EvidenceRequest arrives.  Don't notify, or have TLS
> keep it locked away from the app, etc., depending on the style of
> integration with the server app.  Now if the EvidenceRequest never arrives
> presume it's because the line got cut.  Notify the server app of the socket
> failure without delivering the last app data record.  Now the server app
> faces the same problem that he faces whether he uses TLS, TLS Evidence or
> just a socket, so the server app already needs to be able to deal with that
> problem.

I think "not great" is quite an understatement here. You've just
required that every TLS record write requires *two* signatures,
one from the sender and one from the receiver. This includes
record read/writes which the application doesn't even care
about having evidence for. Your typical brokerage transaction
requires 10s if not hundreds of separate HTTP fetches, each
of which requires one or more record in each direction. Doing
25 digital signatures for every transaction is an enormous
load on the server.

By contrast, message-oriented solutions are inherently more
efficient since you can sign at the message rather than the
record level and moreover you can sign selectively. Yes,
I appreciate you can use alerts, etc. to sign selective
portions of the stream, but now you're getting into the
case of application interaction again.


>> But transaction rollbacks are expensive and complicated. It's much
>> better to simply not perform the transaction if the counterparty
>> hasn't authenticated. Moreover, in this system you *need* to
>> treat a failed evidence handshake (e.g., due to network failures)
>> as an attack and execute a transaction rollback. With ordinary
>> signed messages this isn't true since a network failure just
>> causes the counterparty not to get their receipt.
>> 
>> -Ekr
>
> Yes, it really would be a pain to do transaction rollbacks.  But the premise
> I want to start with is that the cost of a tx rollback has already been
> determined at design time to be less than the cost of getting the tx or its
> evidence wrong.

Sure, but those aren't the only two design choices. In particular,
message-oriented signature schemes don't have this problem. 

-Ekr


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls