Martin's point makes sense to me: applications that need to do authentication upfront can still do that immediately after the handshake.
Cheers, Andrei -----Original Message----- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Wednesday, September 16, 2015 10:48 AM To: Ilari Liusvaara <ilari.liusva...@elisanet.fi> Cc: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] Review of PR #209 On 16 September 2015 at 08:30, Ilari Liusvaara <ilari.liusva...@elisanet.fi> wrote: > Problem with pulling client auth out of the handshake is that it > complicates applications that can't change identities involved with > active connection. Why would that be unsupported here? The server can still send CertificateRequest immediately after its Finished. That looks exactly like it does today, only the order has changed. > 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. >> 2. The client can send Certificate and CertificateVerify at any time >> application data is permitted, regardless of whether the server had >> previously sent CertificateRequest. > > CertificateRequest contains the permitted signature algorithms for the > PoP signature, which TLS library needs to verify before dumping the > certificate chain on application (which can then figure out things > like trust anchors). > > Without CertificateRequest, one has little idea what algorithms are > acceptable there. Arguably, signature_algorithms covers that adequately. Though I'll grant that certificate chain validation often happens in a separate component to the TLS stuff. > Basically, one must clear the pipeline before changing identities, and > with protocols like HTTP/2, this is extremely expensive (seemingly > even more expensive than establishing a new connecion). There's been some confusion about this with HTTP/2. I think that if you adopt the position that authentication applies to the entire session - even retroactively - then the only remaining concern is the correlation one. If you have three tabs to the site open where all of them are making requests and you see a certificate request, which one do you pop the dialog on? > Also, it should sign the certificate, to avoid possible weirdness due > to signatures not properly binding the key (some schemes do, most > don't). I agree with this. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
