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

[Martin Rex <martin.rex@xxxxxxx>]

Eric Rescorla wrote:
>
> Mark Brown wrote: 
> > 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.

In many existing deployments its even magnitudes more complicated,
and it becomes exteremly obvious that TLS Evidence doesn't fit
at all into the TLS architecture.

Think about reverse proxies, "SSL accelerators", load balancers,
which are the entry point to application server farms today and
terminate the SSL/TLS connection and forward optional SSL/TLS client
certificates as header fields to the backend application engines
through various kinds of communication, and sometimes doing
request aggregation on the way.

If the application on the backend system would like to get
"Evidence" of a transaction using TLS evidence, it will have
to jump many hoops to (a) get signalling to the SSL/TLS terminating
host/component in the opposite direction of the regular communication
and also how to get that data re-transferred once it is collected.



Considering that it took Microsoft about >10 years after it was
standardized in the spec to actually support SSL/TLS client certificates
in WinHTTP (I don't know whether the hotfix is generally available yet),
I have little hope of an Evidence concept requiring client certificates
to go anywhere fast.

If you do consider "Evidence" for customers of Web Shops / Online Services
useful, then a proposal that can not do without client certs is a pretty
dumb approach.  The use of client certs is still extremely limited,
otherwise the shortcomings in Microsoft's WinHTTP would have been
noticed and fixed long before shipment.


As has been said before, secure receipts can be easily implemented
with the existing technology, with only a small application plugin
at the backend side and no changes to the middleware and no changes
to the client software.  Actually, several solutions are in
active use for over a year, some even with truely legally binding
digital signatures!


-Martin

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