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

[Carl Wallace <[e-mail]>]

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 <[e-mail]>
Date:  Tuesday, May 29, 2018 at 1:49 PM
To:  Carl Wallace <[e-mail]>
Cc:  <[e-mail]>, <[e-mail]>, The
IESG <[e-mail]>
Subject:  Re: secdir review of draft-ietf-httpbis-h2-websockets

> Hey Carl, thanks for doing this
> 
> On Tue, May 29, 2018 at 1:32 PM, Carl Wallace <[e-mail]>
> wrote:
>> 
>> 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?
>> 
> 
> 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
> 
> 
>