I should add: I do think this general line of consolidating all the client auth modes is a good idea, assuming we can work out the details.
-Ekr On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla <e...@rtfm.com> wrote: > I think the potential issue here is needing a way for the server to tell > the > client "don't bother sending me data until you've authenticated" (though, > as MT says, you could argue that the client's signature retroactively > authenticates, which does seem like the simplest way to think about > things). > > One might imagine dealing with that by a simple signal in a ServerHello > extension that said "authentication will be required, sit tight..." > > -Ekr > > > On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov <andrei.po...@microsoft.com > > wrote: > >> 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 >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
