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

["Martin Thomson" <[e-mail]>]

LGTM.  A simple fix for a known problem that no one really got around to documenting.  This was always the intent, but it never got written down.  Thanks for doing that.

Nit:

The use of "this" in "incompatible with this" is a little unclear.

On Tue, Apr 2, 2019, at 01:23, David Benjamin 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>.