Subject: Working Group Last Call: draft-ietf-httpbis-http2-tls13-00

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Sep 2019 13:15:58 +1000

David indicates that he thinks we're ready for WGLC on this document:

 https://tools.ietf.org/html/draft-ietf-httpbis-http2-tls13-00

Please have a look through and bring up any issues here or on the issues list, and please indicate support (or lack thereof) for advancement on the mailing list. If you are implementing or intend to implement the specification, that would be useful information for us.

WGLC will end on 19 September.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Sep 2019 13:48:13 +1000

LGTM.  With a possible suggestion.

Having just re-reviewed this concise and well-written document, and in tripping over the KeyUpdate piece, I think that we should have more general language about post-handshake messaging in TLS.  Anything that is strictly TLS-specific shouldn't be prohibited by this, but it somewhat implies that.  For instance, the heatbeat extension should be permitted.  

Maybe replace the language about KeyUpdate and instead say something like:

```
4.  Other Post-Handshake TLS Messages in HTTP/2

   Section 9.2.1 of [RFC7540] does not extend to TLS 1.3 messages that are exchanged after the handshake is complete.  This includes KeyUpdate messages, which only affect TLS itself and do not require any interaction with the application protocol.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated.

   Unless the use of a new type of TLS message depends on an interaction with the application layer protocol, that TLS message can be sent after the handshake completes.

   NewSessionTicket messages are explicitly permitted.  Though these interact with HTTP when early data is enabled, these interactions are well defined in RFC 8470 and allowed for in the design of HTTP/2.
```

I realize that this is a change, but I want to ensure that the TLS working group doesn't have to come back and update this document if they decide to add some messaging that only affects the operation of TLS.

Cheers,
Martin

On Thu, Sep 5, 2019, at 13:15, Mark Nottingham wrote:
> Please have a look through and bring up any issues here or on the 
> issues list, and please indicate support (or lack thereof) for 
> advancement on the mailing list. If you are implementing or intend to 
> implement the specification, that would be useful information for us.
>

---

From: David Benjamin <[email-masked]>
Date: Fri, 6 Sep 2019 10:41:34 -0700

My original thinking was that post-handshake auth and KeyUpdate are
relevant because they are spiritual successors of renegotiation in TLS 1.3.
The original RFC7540 targets renegotiation, so we should say something
about how the prohibition applies. For random other features, there isn't
anything existing text targeting them. But saying things more clearly never
hurts, so your replacement text SGTM too.

I do think TLS should be a bit clearer on when a feature is intended to be
transparent and behind the TLS "API" and what is meant to "caller-visible".
Features in the latter bucket like post-handshake auth and early data tend
to be rather messy and ought to be gated by an application profile,
otherwise we run into problems like these.

On Wed, Sep 4, 2019 at 8:51 PM Martin Thomson <[email-masked]> wrote:

> Having just re-reviewed this concise and well-written document, and in
> tripping over the KeyUpdate piece, I think that we should have more general
> language about post-handshake messaging in TLS.  Anything that is strictly
> TLS-specific shouldn't be prohibited by this, but it somewhat implies
> that.  For instance, the heatbeat extension should be permitted.
>
>    Section 9.2.1 of [RFC7540] does not extend to TLS 1.3 messages that are
> exchanged after the handshake is complete.  This includes KeyUpdate
> messages, which only affect TLS itself and do not require any interaction
> with the application protocol.  HTTP/2 implementations MUST support key
> updates when TLS 1.3 is negotiated.
>
>    Unless the use of a new type of TLS message depends on an interaction
> with the application layer protocol, that TLS message can be sent after the
> handshake completes.
>
>    NewSessionTicket messages are explicitly permitted.  Though these
> interact with HTTP when early data is enabled, these interactions are well
> defined in RFC 8470 and allowed for in the design of HTTP/2.
> ```
>
> I realize that this is a change, but I want to ensure that the TLS working
> group doesn't have to come back and update this document if they decide to
> add some messaging that only affects the operation of TLS.
>
> Cheers,
> Martin
>

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 07 Sep 2019 16:53:35 -0700

On Fri, Sep 6, 2019, at 10:41 AM, David Benjamin wrote:
> relevant because they are spiritual successors of renegotiation in TLS 
> 1.3. The original RFC7540 targets renegotiation, so we should say 
> something about how the prohibition applies. For random other features, 
> there isn't anything existing text targeting them. But saying things 
> more clearly never hurts, so your replacement text SGTM too.
> 
> I do think TLS should be a bit clearer on when a feature is intended to 
> be transparent and behind the TLS "API" and what is meant to 
> "caller-visible". Features in the latter bucket like post-handshake 
> auth and early data tend to be rather messy and ought to be gated by an 
> application profile, otherwise we run into problems like these.

+1!

Best,
Chris

---

From: Mike Bishop <[email-masked]>
Date: Mon, 9 Sep 2019 17:44:27 +0000

Giving this document a re-read, I take some issue with one wording choice that seems to be consistent throughout:
~~~
   The former shares the same problems with multiplexed protocols, but
   has a different name.  This makes it ambiguous whether post-handshake
   authentication is allowed in TLS 1.3.

   This document clarifies that the prohibition applies to post-
   handshake authentication but not to key updates.
~~~
It's not at all ambiguous whether the prohibitions in RFC7540 apply to TLS 1.3 -- they don't.    "Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only support and use the SNI extension; deployments of TLS 1.2 are subject to the requirements in the following sections."  The sections you're discussing are very explicitly excluded from covering TLS 1.3.

But the reasons for them still apply, so you're here defining those prohibitions against the new world of TLS 1.3.  This isn't a clarification of anything formerly ambiguous, but a new definition in the same spirit and for the same reason.

The requirements themselves, I support.

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: Wednesday, September 4, 2019 11:16 PM
To: HTTP Working Group <[email-masked]>
Cc: Tommy Pauly <[email-masked]>; Patrick McManus <[email-masked]>
Subject: Working Group Last Call: draft-ietf-httpbis-http2-tls13-00

Cheers,

---

From: David Benjamin <[email-masked]>
Date: Wed, 11 Sep 2019 20:34:33 -0400

On Mon, Sep 9, 2019 at 1:52 PM Mike Bishop <[email-masked]> wrote:

> It's not at all ambiguous whether the prohibitions in RFC7540 apply to TLS
> 1.3 -- they don't.    "Deployments of HTTP/2 that negotiate TLS 1.3 or
> higher need only support and use the SNI extension; deployments of TLS 1.2
> are subject to the requirements in the following sections."  The sections
> you're discussing are very explicitly excluded from covering TLS 1.3.
>

Aha! Somehow I'd missed that sentence. Thanks! I've applied MT's suggestion
and then reworded the document accordingly in
https://github.com/httpwg/http-extensions/pull/929.

> But the reasons for them still apply, so you're here defining those
> prohibitions against the new world of TLS 1.3.  This isn't a clarification
> of anything formerly ambiguous, but a new definition in the same spirit and
> for the same reason.
>
> Please have a look through and bring up any issues here or on the issues
> list, and please indicate support (or lack thereof) for advancement on the
> mailing list. If you are implementing or intend to implement the
> specification, that would be useful information for us.
>

---

From: David Benjamin <[email-masked]>
Date: Fri, 13 Sep 2019 18:51:06 -0400

I've now uploaded draft-ietf-httpbis-http2-tls13-01 which includes that PR.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-tls13-01 (link doesn't
work as of writing but presumably will work later)
https://www.ietf.org/id/draft-ietf-httpbis-http2-tls13-01.txt
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-http2-tls13-01

On Wed, Sep 11, 2019 at 8:34 PM David Benjamin <[email-masked]>
wrote:

>> It's not at all ambiguous whether the prohibitions in RFC7540 apply to
>> TLS 1.3 -- they don't.    "Deployments of HTTP/2 that negotiate TLS 1.3 or
> Aha! Somehow I'd missed that sentence. Thanks! I've applied MT's
> suggestion and then reworded the document accordingly in
>> Cc: Tommy Pauly <[email-masked]>; Patrick McManus <[email-masked]
>> >

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 15 Sep 2019 14:06:49 +1000

Folks, please have a read of the diff below, and say whether or not it addresses the WGLC comments. WGLC will end later this week.

Cheers,

> On 14 Sep 2019, at 8:51 am, David Benjamin <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-tls13-01 (link doesn't work as of writing but presumably will work later)
> On Wed, Sep 11, 2019 at 8:34 PM David Benjamin <[email-masked]> wrote:
> Aha! Somehow I'd missed that sentence. Thanks! I've applied MT's suggestion and then reworded the document accordingly in https://github.com/httpwg/http-extensions/pull/929.
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Sep 2019 20:14:53 +0000

Looks good to me -- ship it!

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: Sunday, September 15, 2019 12:07 AM
To: David Benjamin <[email-masked]>
Cc: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>; Tommy Pauly <[email-masked]>; Patrick McManus <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-httpbis-http2-tls13-00

Cheers,

> https://tools.ietf.org/html/draft-ietf-httpbis-http2-tls13-01 (link 
> doesn't work as of writing but presumably will work later)