[TLS] In-handshake CertificateRequest and 0-RTT

[David Benjamin <[e-mail]>]

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.)

This makes 6.2.3 more consistent with 6.2.2 where neither side
authenticates in a resumption handshake. 0-RTT is much more similar to
resumption with most parameters carrying over anyway.

1-RTT client auth in a 0-RTT handshake also invites more of the retroactive
auth confusion as with post-handshake auth. The client stream switches from
unauthenticated to authenticated. I believe this was one of the reasons we
agreed at IETF 95 to discourage/forbid (not sure which) sending 0.5-RTT
data following a CertificateRequest. In-handshake CertificateRequest either
requires this discouraged situation or accepting 0-RTT data without sending
0.5-RTT data, which is largely pointless.

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. 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.

In both cases, excluding post-handshake auth should exclude any transition
from unauthenticated to authenticated in the stream. Instead, if you want
to change authentication state, send a post-handshake CertificateRequest,
as you would have normally.

David