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

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 <mt@lowentropy.net> wrote:

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