On Tue, Sep 15, 2015 at 08:17:56PM +0000, Andrei Popov wrote: > Perhaps we can simplify the protocol by pulling client auth out of the > handshake as follows:
Problem with pulling client auth out of the handshake is that it complicates applications that can't change identities involved with active connection. And applications that can't take dynamic identites may still be able to take static identities. As then the application needs to ensure that the authentication occurs between TLS handshake and actually starting up the protocol. > 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. > 3. The server can send CertificateRequest and NewSessionTicket at any > time application data is permitted. Alternatively, the server can > encapsulate CertificateRequest in an application protocol message. If done with protocols that can't support dynamic authentication properly, doing that tends not show up as things visibly breaking, it tends to show up as subtle security holes. Also, that doesn't properly bind NST with state is for (as already noted), possibly causing screwy behaviour if TLS resumption is attempted (client and server not agreeing on client identity, which actually breaks definition of secure key exchange outright). > Encapsulating CertificateRequest in an application protocol message > allows the client to determine which specific application request > resulted in the need for client auth. The application protocols that would indicate this seem to be pretty much the ones where dynamic authentication is unsafe. 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). > We can decide exactly what CertificateVerify would be signing: > whether it's the handshake hash or some form of RFC5705 Exported > Keying Material (EKM). Also, it should sign the certificate, to avoid possible weirdness due to signatures not properly binding the key (some schemes do, most don't). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
