I think that this is a fine way to simplify, but I have a wrinkle to add. I would rather this be formulated as: a client cannot authenticate using Certificate[+Verify] unless the server does so first.
The reason that I want that is this issue https://github.com/tlswg/tls13-spec/issues/443 I want to be able to do 0-RTT but have the server continue to prove that it has the private key (maybe some clients will do that occasionally). For those, I think that reciprocating is reasonable. It doesn't significantly change the state machine in that case. I hope to write a draft explaining this soon, so that folks can see what it costs/looks like. On 12 May 2016 at 06:44, David Benjamin <david...@chromium.org> wrote: > The 0-RTT handshake originally had two places with a client Certificate + > CertificateVerify: in the 0-RTT flow and in the second Finished block in > response to a server CertificateRequest. We've dropped the first now. I > propose we drop the second too. Client auth with 0-RTT is solely carried > over via resumption. (I mentioned this previously, but with 0-RTT looking > closer to resumption and the IETF 95 decision on 0.5-RTT data, I think the > case is clearer.) > We accepted the retroactive auth issue in post-handshake auth, but I think > we should limit it to that. For implementations, BoringSSL made accepting > renego an opt-in feature. I expect we'd do the same for post-handshake auth. I totally agree about the post-handshake stuff. I'm somewhat inclined to ask that it be made an extension so that you can cleanly opt out. > For specs, one might specify that post-handshake authentication is > forbidden. HTTP/2 did this for renegotiation. I haven't been following the > HTTP/2 client cert saga as closely, but draft-thomson-http2-client-certs-02 > is the current plan, right? If so, HTTP/2 should forbid TLS-level > post-handshake auth too. We're doubling down on that idea and considering allowing the server to authenticate too. See https://mikebishop.github.io/http2-client-certs/ (you might recognize some similarity to the SPDY CREDENTIAL frame if you squint hard enough). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
