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

From: David Benjamin <[email-masked]>
Date: Mon, 1 Apr 2019 18:19:41 -0500

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 02 Apr 2019 09:32:54 -0400

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

---

From: David Benjamin <[email-masked]>
Date: Tue, 2 Apr 2019 10:26:15 -0500

On Tue, Apr 2, 2019 at 8:36 AM Martin Thomson <[email-masked]> wrote:

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

I've replaced that clause in my local copy with "which is incompatible with
the mechanism above".

> > <
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03#section-1.2.1>.
> Thus, HTTP/2 forbids renegotiation <
> https://tools.ietf.org/html/rfc7540#section-9.2.1>.
> >

---

From: Patrick McManus <[email-masked]>
Date: Thu, 4 Apr 2019 15:22:03 +0200

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

---

From: David Benjamin <[email-masked]>
Date: Thu, 4 Apr 2019 10:37:19 -0500

Sure. Whatever you all think makes sense. I don't really know the usual
process for these things.

On Thu, Apr 4, 2019 at 8:22 AM Patrick McManus <[email-masked]> wrote:

>> is internal to the TLS stack and works just fine in existing servers[*].