As dkg points out, dynamically authenticating clients later in the connection brings up API issues of how to notify the application about the scope of this new authentication event.
I think it is inevitable that implementation will store the client credential in the session, and that the new (authenticated) stream of data will be concatenated to the older (unauthenticated) stream. Both of these design choices will lead to the following answers to dkg’s questions: (a) all messages in TLS sessions (past and present) will be attested to by every certificate (b) all traffic in earlier and future resumed sessions will be attested to by every certificate In other words, if we do allow this change to client authentication, to be safe, we must analyze the resulting protocol *as if* applications will use the authentication event to attest to all data, past and present, that may be associated with the data in the current connection. -K. > On 19 Sep 2015, at 22:14, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > > On Wed 2015-09-16 13:48:27 -0400, Martin Thomson <martin.thom...@gmail.com> > wrote: >> On 16 September 2015 at 08:30, Ilari Liusvaara <ilari.liusva...@elisanet.fi> >> wrote: >>> As then the application needs to ensure that the authentication >>> occurs between TLS handshake and actually starting up the protocol. >> >> I'm not sure that is necessarily a problem. If the claim is that the >> authentication attests to everything prior to its appearance, then you >> have no problem. I think that claim is reasonable, but I'm happy to >> discuss it. > > I think this claim sounds confusing, for (at least) two reasons: > > (a) it interacts oddly with the possibility of > 1 CertificateVerify > message -- does it imply that all messages in a TLS session > (past and present) are attested to by every client certificate ever > sent in the session? > > (b) it has unclear semantics around session resumption. If i resume a > session and send a ClientCert+CertificateVerify, am i retroactively > attesting to all the communications from the previous session(s)? > What does that even mean to the server which has already processed > the traffic from previous sessions? > > Can we communicate these semantics to application developers who might > have an "accelerating" TLS session cache available, or who might share a > session cache between systems? Can we help clients make sense of the > implications of retroactive attestation when confronted with a > certificateRequest? > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
