Subject: [secdir] secdir review of draft-ietf-httpbis-h2-websockets

From: Carl Wallace <[email-masked]>
Date: Tue, 29 May 2018 13:32:25 -0400

I have reviewed this document as part of the security directorate’s
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This document defines a mechanism for running the WebSocket Protocol (RFC
6455 ) over a single stream of an HTTP/2 connection. The mechanism takes
the form of a new SETTINGS parameter and a new pseudo-header. The document
is well-written and I see no issues with it other than some friction with
this statement in section 8.1.2.1 of RFC7540:

	"Endpoints MUST NOT generate pseudo-header fields other than those
defined in this document."

The draft-ietf-httpbis-h2-websockets defines a new pseudo-header field in
section 4. Section 3 addresses extending HTTP/2 via a reference to section
5.5 of RFC7540, but there was nothing in that section to relax the
prohibition on using pseudo-header fields not defined by 7540. Is a mod to
7540 necessary to enable support for the mechanism in
draft-ietf-httpbis-h2-websockets?

One minor nit, section 3 states "a sender MUST NOT send a
SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after
previously sending a value of 1". This reads as though one could never
turn off web socket support once enabled.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 May 2018 13:49:39 -0400

Hey Carl, thanks for doing this

> draft-ietf-httpbis-h2-websockets?
imo no update to 7540 is needed. the wg also considered the question and
had the same conclusion. I will highlight the reasoning:

5.5 <https://tools.ietf.org/html/rfc7540#section-5.5>.  Extending HTTP/2

   HTTP/2 permits extension of the protocol.  Within the limitations
   described in this section, protocol extensions can be used to provide
   additional services or alter any aspect of the protocol.  Extensions
   are effective only within the scope of a single HTTP/2 connection.

note "alter any aspect of this protocol"

[..]

   Extensions that could change the semantics of existing protocol
   components MUST be negotiated before being used.

This is one of the limitations mentioned above.. so the websockets
extension needs to be negotiated (and it is).

[..] For example, an extension that changes the layout of the HEADERS frame
cannot be used until the peer has given a positive signal that this is
acceptable.
 In this case, it could also be necessary to coordinate when the revised
layout comes into effect. Note that treating any frames other than DATA
frames as flow controlled is such a change in semantics and can only be
done through negotiation.

These two examples are also powerful citations that negotiated extensions
can change the interpretation of basic pieces of 7540 such as existing
frame layouts and even flow control rules (both of which have MUSTs
associated with them).

The whole section is a little bit confusing because it also enumerates a
few extension points that the websockets draft is not using. But those are
specifically enumerated because they can be used without negotiated opt-in
and implementations not aware of the extensions need to take care to keep
them clean and available for extending (so there are requirements even if
you're not implementing the extension). As the example paragraph shows,
extensions are not solely limited to that model.

Cheers
-Patrick

---

From: Carl Wallace <[email-masked]>
Date: Tue, 29 May 2018 15:37:02 -0400

Your reasoning makes sense but it requires an awfully careful reading to
counter the clarity of the prohibition on new pseudo-headers. Maybe an
errata could be filed against 7540 to clarify the "alter any aspect of this
protocol" where the prohibition  is asserted for the benefit of future
readers. For example, something like "Endpoints MUST NOT generate
pseudo-header fields other than those defined in this document, except where
support for additional pseudo-headers is negotiated as permitted in section
5.5" would help.

From:  Patrick McManus <[email-masked]>
Date:  Tuesday, May 29, 2018 at 1:49 PM
To:  Carl Wallace <[email-masked]>
Cc:  <[email-masked]>, <[email-masked]>, The
IESG <[email-masked]>
Subject:  Re: secdir review of draft-ietf-httpbis-h2-websockets

> imo no update to 7540 is needed. the wg also considered the question and had
> the same conclusion. I will highlight the reasoning:
> 
> 5.5 <https://tools.ietf.org/html/rfc7540#section-5.5> .  Extending HTTP/2
> 
> 
> This is one of the limitations mentioned above.. so the websockets extension
> needs to be negotiated (and it is).
> [..] For example, an
>    extension that changes the layout of the HEADERS frame cannot be used
>    until the peer has given a positive signal that this is acceptable.
>  In this case, it could also be necessary to coordinate when the
>    revised layout comes into effect.  Note that treating any frames
>    other than DATA frames as flow controlled is such a change in
>    semantics and can only be done through negotiation.
> These two examples are also powerful citations that negotiated extensions can
> change the interpretation of basic pieces of 7540 such as existing frame
> layouts and even flow control rules (both of which have MUSTs associated with
> them).
> 
> The whole section is a little bit confusing because it also enumerates a few
> extension points that the websockets draft is not using. But those are
> specifically enumerated because they can be used without negotiated opt-in and
> implementations not aware of the extensions need to take care to keep them
> clean and available for extending (so there are requirements even if you're
> not implementing the extension). As the example paragraph shows, extensions
> are not solely limited to that model.
> 
> Cheers
> -Patrick
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2018 13:23:16 +1000

The problem is that we'd have to put such a caveat on pretty much every MUST in the document. 

Cheers,

> On 30 May 2018, at 5:37 am, Carl Wallace <[email-masked]> wrote:
> 
> Your reasoning makes sense but it requires an awfully careful reading to counter the clarity of the prohibition on new pseudo-headers. Maybe an errata could be filed against 7540 to clarify the "alter any aspect of this protocol" where the prohibition  is asserted for the benefit of future readers. For example, something like "Endpoints MUST NOT generate pseudo-header fields other than those defined in this document, except where support for additional pseudo-headers is negotiated as permitted in section 5.5" would help.
> 
> Cc: <[email-masked]>, <[email-masked]>, The IESG <[email-masked]>
>> On Tue, May 29, 2018 at 1:32 PM, Carl Wallace <[email-masked]> wrote:
>>> 
>> imo no update to 7540 is needed. the wg also considered the question and had the same conclusion. I will highlight the reasoning:
>> 
>> 5.5.  Extending HTTP/2
>> 
>> 
>> 
>> This is one of the limitations mentioned above.. so the websockets extension needs to be negotiated (and it is).
>> [..] For example, an
>> These two examples are also powerful citations that negotiated extensions can change the interpretation of basic pieces of 7540 such as existing frame layouts and even flow control rules (both of which have MUSTs associated with them).
>> 
>> The whole section is a little bit confusing because it also enumerates a few extension points that the websockets draft is not using. But those are specifically enumerated because they can be used without negotiated opt-in and implementations not aware of the extensions need to take care to keep them clean and available for extending (so there are requirements even if you're not implementing the extension). As the example paragraph shows, extensions are not solely limited to that model.
>> 
>> Cheers
>> -Patrick
>> 
>> 
>> 

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

---

From: Carl Wallace <[email-masked]>
Date: Thu, 31 May 2018 06:18:29 -0400

Good enough. 

> On May 30, 2018, at 11:23 PM, Mark Nottingham <[email-masked]> wrote:
>