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

From: Ben Campbell <[email-masked]>
Date: Wed, 06 Jun 2018 12:36:00 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-httpbis-h2-websockets-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-h2-websockets/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just a couple of minor comments:

Substantive:
§5: Is the scheme pseudo-header expected to match the security status of the
existing connection?

Editorial:
§4, first bullet: This sort of deep link into the IANA registries makes it hard
for them to evolve their registry organization over time. Please consider
referencing the registry by name.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 6 Jun 2018 22:26:15 +0200

On 2018-06-06 21:36, Ben Campbell wrote:
> ...
> ...

We've been doing that for quite some time and IANA did not object to it.

FWIW, <https://www.w3.org/Provider/Style/URI>.

Best regards, Julian

---

From: Patrick McManus <[email-masked]>
Date: Thu, 7 Jun 2018 10:13:52 +0200

Hi Ben, thanks for the review -

> §5: Is the scheme pseudo-header expected to match the security status of
7540 indicates the security requirements for carrying https or http
schemes, which conveniently are the schemes used by this draft.

The draft doesn't require that you use the connection that the markup was
received on - though that's obviously desirable when possible.

> referencing the registry by name.
Julian replied here, and the current reference style is based on a last
call comment from him. If you believe this needs to be changed after that
discussion please flag explicitly so we can get the right people together.
Personally, I'm agnostic on the issue.

Thanks!

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Jun 2018 17:01:17 -0500

> On Jun 7, 2018, at 3:13 AM, Patrick McManus <[email-masked]> wrote:
> 
> 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. And you are also disallowed to setup a tunnel for “ws” if the stream is running over a connection setup for HTTPS?

> 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?

> Julian replied here, and the current reference style is based on a last call comment from him. If you believe this needs to be changed after that discussion please flag explicitly so we can get the right people together. Personally, I'm agnostic on the issue.
> 

I can live with it as is.

Thanks!

Ben.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 10 Jun 2018 18:50:30 -0500

On Thu, Jun 7, 2018 at 5:01 PM, Ben Campbell <[email-masked]> wrote:

> 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.

> > 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)

---

From: Ben Campbell <[email-masked]>
Date: Mon, 11 Jun 2018 20:44:09 -0500

> On Jun 10, 2018, at 6:50 PM, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
> 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 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.