HTTP/2 and TLS 1.3 post-handshake authenication

Hi all,

HTTP/2 and TLS 1.3 have a minor incompatibility around post-handshake
authentication. Mike Bishop suggested that, rather than add some text in
the secondary certs draft, it would better to make a separate document that
actually updates HTTP/2. I've done so and uploaded a draft.
https://tools.ietf.org/html/draft-davidben-http2-tls13-00
https://www.ietf.org/id/draft-davidben-http2-tls13-00.txt

HTTP/2 was specified against TLS 1.2, which had a renegotiation mechanism
to rekey the connection. It additionally changed parameters, so in
HTTP/1.1, this is often used in a hack to implement reactive client auth
<https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03#section-1.2.1>.
This hack doesn't work in a multiplexed protocol like HTTP/2, because the
client cannot tell which request triggered the authentication request.
Thus, HTTP/2 forbids renegotiation
<https://tools.ietf.org/html/rfc7540#section-9.2.1>.

TLS 1.3 removed renegotiation and replaced it with two features: a
lightweight key update, and post-handshake client authentication. The
former is meant to be transparent and is compatible with HTTP/2. The latter
reintroduces renegotiation's multiplexing problems. There is no spec text
which says how to interpret HTTP/2's existing renegotiation ban in TLS 1.3.

The draft fixes it by documenting the status quo. KeyUpdate is fine. It is
internal to the TLS stack and works just fine in existing servers[*].
Post-handshake auth is forbidden. No existing servers request it because
they already do not request renegotiation, and no existing clients accept
it because they cannot usefully interpret it. Instead, the reactive client
auth use case for HTTP/2 is instead being covered
by draft-ietf-httpbis-http2-secondary-certs.

Note it's not sufficient to lean on the TLS 1.3 post_handshake_auth
extension because that extension is not correlated with ALPN. A client may
wish to support post-handshake auth with HTTP/1.1, for continuity with the
TLS 1.2 renego hack, while still supporting HTTP/2.

David

[*] Aside from an OpenSSL bug
<https://mailarchive.ietf.org/arch/msg/tls/Aw1WY5gBAifAZXowgx5Ym82RIKI> which,
pertinently, made some applications misinterpret it as a renegotiation to
be blocked. That bug has been fixed in OpenSSL 1.1.1b
<https://www.openssl.org/news/changelog.html#x1>.