On 27 January 2016 at 12:58, David Benjamin <david...@chromium.org> wrote: > If the server needs to send a CertificateRequest (i.e. the client > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a > 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but > useless because the first authenticated byte of the response is delayed to > t=1.5. We should just say that 0-RTT accept + CertificateRequest is > forbidden.
I believe that is a choice that an implementation could make, rather than have a stipulation in a spec. You are free to simplify in your implementation as much as you like. Refusing 0-RTT and delaying the "completion" of a handshake if you find that you need to send a CertificateRequest (either because you don't have 0-RTT client auth or the 0-RTT client auth is bad/indecipherable) is a pretty good choice. I might even be happy to recommend it to others. But do you have a security property you are looking to preserve? Because otherwise, I think that I might take the optimization. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
