Re: HTTP/2 and TLS 1.3 post-handshake authenication

David, this looks good and obvious to me. Would you like the chairs to
discuss issuing a working group call for adoption for it?

On Tue, Apr 2, 2019 at 1:23 AM David Benjamin <davidben@chromium.org> wrote:

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