Perhaps we can simplify the protocol by pulling client auth out of the handshake as follows:
1. CertificateRequest, client Certificate, CertificateVerify and NewSessionTicket messages use a new content type distinct from "handshake". 2. The client can send Certificate and CertificateVerify at any time application data is permitted, regardless of whether the server had previously sent CertificateRequest. 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. 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 protocol would of course need to allow this. As far as I can tell, the above scheme seems to work in both 0-RTT and 1-RTT modes. We can decide exactly what CertificateVerify would be signing: whether it's the handshake hash or some form of RFC5705 Exported Keying Material (EKM). Thoughts? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: Saturday, July 25, 2015 8:00 AM To: tls@ietf.org Subject: [TLS] Review of PR #209 Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209 The first expands the ways in which a server can identify certificates. This is fine. I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately). The second is worrisome. I don't like that a handshake message now has two different potential locations that it might appear in. That seems like a hazard. I think that we need a new content type for a new message that can be used after the handshake completes. Then there are two options: a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses) b) use CertificateRequest within the handshake, and the new content type outside of it _______________________________________________ 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
