W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2019

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

From: Martin Thomson <mt@lowentropy.net>
Date: Tue, 02 Apr 2019 09:32:54 -0400
Message-Id: <36b4ac76-05b2-4ec6-a35c-db6a5057d798@www.fastmail.com>
To: ietf-http-wg@w3.org
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.


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>.
Received on Tuesday, 2 April 2019 13:33:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC