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

On Tue, Apr 2, 2019 at 8:36 AM Martin Thomson <mt@lowentropy.net> 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:
>
> The use of "this" in "incompatible with this" is a little unclear.
>

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


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