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

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

"Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx> writes:
> Since I've run this example while dropping alerts, no start1, etc. are
> required and all application data will generate evidence until the session
> is terminated.  If alerts are dropped, then a fairly "safe" rule for
> evidence generation is to require that every time client or server dumps a
> stream of application data to TLS records and to the wire (a single TLS
> write call by the app) an EvidenceRequest also be created and sent.

Yes, but how does the *app* know that?


> The TLS
> layer simply lets the app layer set the pace in this no-alerts proposal.
> Since I'm provisionally dropping alerts here, I think it's best to NOT reset
> the TLS Evidence application_data hashes any time during the session -- just
> let them accumulate across all Evidence- messages for the session.  My
> example of this is shown below:
>
>       ApplicationData-1         -------->    [Client's instructions]
>       EvidenceRequest-1         -------->
>                                 <--------    EvidenceResponse-1
>       [Server's response]       <--------    ApplicationData-2

But there's a race condition here. The server doesn't know that
an EvidenceRequest-1 message is coming, so how does it know
to wait for it before executing whatever transaction the client
requested? Remember that TLS is a stream protocol, so the only
boundaries are at the higher layer.

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.




> Threats I've considered include: client or server "hangs up" at an opportune
> moment in the exchange, one sends garbage, one sends something unexpected in
> the app data.  I think all of these threats pose little risk to the parties
> because of two facts.
>
> 1) before either party gets their EvidenceResponse, they can walk away and
> claim "it didn't happen."

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

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