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

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 <mcmanus@ducksong.com> wrote:

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