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

Patrick McManus <pmcmanus@mozilla.com> Tue, 29 May 2018 17:49 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6095712D87B; Tue, 29 May 2018 10:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level:
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkW5vabRX0Bd; Tue, 29 May 2018 10:49:41 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id CC28512E9DC; Tue, 29 May 2018 10:49:40 -0700 (PDT)
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id 2AC6E3A03C; Tue, 29 May 2018 13:49:40 -0400 (EDT)
Received: by mail-oi0-f48.google.com with SMTP id l1-v6so13851985oii.1; Tue, 29 May 2018 10:49:40 -0700 (PDT)
X-Gm-Message-State: ALKqPwcQTR8NoaVGyPRcnC7m3RE6TK2M6+nm4SWoddWkk0R0vDmSTKib KL3rfHG6cYl5RdlVpffqMXy8g6M2E1dDwbujV9k=
X-Google-Smtp-Source: ADUXVKLWeuQqHI3TiGPVBv6LyHIIM6uNMQcjwtA0JRJGQoVKShDoePPgYNwB401wVZLw6uP69CH29fjIPwTA3CBDAqs=
X-Received: by 2002:aca:1a06:: with SMTP id a6-v6mr97531oia.213.1527616179783; Tue, 29 May 2018 10:49:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Tue, 29 May 2018 10:49:39 -0700 (PDT)
In-Reply-To: <D73306E9.B8C32%carl@redhoundsoftware.com>
References: <D73306E9.B8C32%carl@redhoundsoftware.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 29 May 2018 13:49:39 -0400
X-Gmail-Original-Message-ID: <CAOdDvNpiYqG4zpMQgiB2MXjHbL0CTuP9NgXh3AVTkFxeFTCK6Q@mail.gmail.com>
Message-ID: <CAOdDvNpiYqG4zpMQgiB2MXjHbL0CTuP9NgXh3AVTkFxeFTCK6Q@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Cc: draft-ietf-httpbis-h2-websockets.all@ietf.org, secdir@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bfdb41056d5bdbd5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/FqtOAt2FaZ1vNUns8ji5iFfxtcQ>
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-h2-websockets
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 17:49:45 -0000

Hey Carl, thanks for doing this

On Tue, May 29, 2018 at 1:32 PM, Carl Wallace <carl@redhoundsoftware.com>
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