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
