Re: [TLS] In-handshake CertificateRequest and 0-RTT

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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).