Re: Ben Campbell's Yes on draft-ietf-httpbis-h2-websockets-06: (with COMMENT)

Ben Campbell <ben@nostrum.com> Tue, 12 June 2018 01:47 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539AC130DD1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Jun 2018 18:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.651
X-Spam-Level:
X-Spam-Status: No, score=-7.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 opUPA7WRp7AK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Jun 2018 18:47:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48BA130DC3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 Jun 2018 18:47:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1fSYMa-0005g2-0H for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Jun 2018 01:44:48 +0000
Resent-Date: Tue, 12 Jun 2018 01:44:48 +0000
Resent-Message-Id: <E1fSYMa-0005g2-0H@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ben@nostrum.com>) id 1fSYMX-0005fP-5b for ietf-http-wg@listhub.w3.org; Tue, 12 Jun 2018 01:44:45 +0000
Received: from raven.nostrum.com ([69.55.229.100] helo=nostrum.com) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <ben@nostrum.com>) id 1fSYMU-0008O1-46 for ietf-http-wg@w3.org; Tue, 12 Jun 2018 01:44:44 +0000
Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5C1iAjD084183 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Jun 2018 20:44:11 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <BE5375BA-F4BE-438D-AB89-B54D67F2073D@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_928B81B0-7EB0-4AB7-B221-FC9D9F9ACBDA"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Mon, 11 Jun 2018 20:44:09 -0500
In-Reply-To: <CAOdDvNqd-6v9dy3Zc5MoLGQzh_wnAgNrGydPx5YPAez_78OJ=w@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-h2-websockets@ietf.org, Mark Nottingham <mnot@mnot.net>, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
To: Patrick McManus <pmcmanus@mozilla.com>
References: <152831376077.6268.4686398668171923624.idtracker@ietfa.amsl.com> <CAOdDvNo-EiKt9Pey2KCtAOW4ZC6vAUobEMz6_4XbNiWaHrmyjg@mail.gmail.com> <A43F472C-980F-4CAE-B18B-60F29BFC4028@nostrum.com> <CAOdDvNqd-6v9dy3Zc5MoLGQzh_wnAgNrGydPx5YPAez_78OJ=w@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-0.096, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1fSYMU-0008O1-46 3e6846b64847bb6875a18d2c12cb79a2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Ben Campbell's Yes on draft-ietf-httpbis-h2-websockets-06: (with COMMENT)
Archived-At: <https://www.w3.org/mid/BE5375BA-F4BE-438D-AB89-B54D67F2073D@nostrum.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35537
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>


> On Jun 10, 2018, at 6:50 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> 
> 
> On Thu, Jun 7, 2018 at 5:01 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> 
> > On Jun 7, 2018, at 3:13 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> >
> > Hi Ben, thanks for the review -
> >
> >
> > On Wed, Jun 6, 2018 at 9:36 PM, Ben Campbell <ben@nostrum.com> wrote:
> >
> > Substantive:
> > §5: Is the scheme pseudo-header expected to match the security status of the
> > existing connection?
> >
> >
> > 7540 indicates the security requirements for carrying https or http schemes, which conveniently are the schemes used by this draft.
> >
> 
> Okay, let me check my understanding here.
> 
> If I want to setup a tunnel for “wss” , :scheme must be https, and that’s only possible if the connection for the stream is running over TLS.
> 
> right
> 
> And you are also disallowed to setup a tunnel for “ws” if the stream is running over a connection setup for HTTPS?
> 
> ws uses the http :scheme, and the rules for doing that with TLS and h2 are set by RFC 8164 if a client really wants to. In most cases though they will just continue to use http/1 as that's what's normal for http:// resources.

Ah, got it. I think it would be helpful for this draft to elaborate a bit on the relationships between the websocket scheme and the security properties of the channel when used with h2. I’m not looking for detail; just a few sentences to explain what you just explained to me.


> 
> 
> > The draft doesn't require that you use the connection that the markup was received on - though that's obviously desirable when possible.
> 
> I’m a bit confused by that statement. I understand this mechanism to upgrade an existing stream to WebSocket. How would you do that on a different connection?
> 
> 
> The term upgrade is a bit confusing, but it is inherited from 6455. Everything needs to start with http(s) and then be turned into (i.e. upgraded into) websockets. You can do that with a new http connection. (the term upgrade comes from the h1 request header named upgrade to this in an h1 context)

I think this part is now academic, and should not delay progressing the document. But for my own education...

Thinking about CONNECT in the general case: When you say “new http connection” do you mean a new connection between the client and the proxy or server, or a new connection between a proxy and a server resulting from CONNECT?

Thanks!

Ben.