Subject: [hybi] Formal declaration of consensus: HTTP Compliance

From: Salvatore Loreto <[email-masked]>
Date: Thu, 05 Aug 2010 18:03:59 +0200

Ticket #1 in the tracker issues:

Based on the charter's clear text about the WG defining a mechanism 
between existing HTTP entities
with as much compatibility as possible, and based on rough consensus on 
the mailing list:

    - HTTP (typically on ports 80 and/or 443) the WebSocket protocol
    will be HTTP compliant until Upgrade
    exchange is completed
    - The WG's focus is on leveraging existing HTTP-based
    infrastructure, although a future rechartering could
    investigate other alternatives.

Joe Hildebrand and Salvatore Loreto
as chairs

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 06 Aug 2010 10:01:00 +0200

>     investigate other alternatives.

I asked a question about potentially using  
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg while this was  
presented and there was at least some agreement that this should not be  
excluded from the options we have, including from at least one of the  
chairs, if I remember correctly.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Adam Barth <[email-masked]>
Date: Fri, 6 Aug 2010 01:11:43 -0700

> chairs, if I remember correctly.

Also, the main advocates for a TLS+NPN based handshake (Maciej and
myself) weren't present at the face-to-face meeting.  I don't see that
we've reached a rough consensus on this point at all.  I'm certainly
not as experienced in IETF process as Salvatore, but we seem to be
jumping the gun here.

Adam

---

From: Dave Cridland <[email-masked]>
Date: Fri, 06 Aug 2010 09:24:48 +0100

> not as experienced in IETF process as Salvatore, but we seem to be

As I recall, EKR made the point that TLS+NPN has yet to go through  
the standards process, so would be problematic from that standpoint.

It's not that anyone's arguing that it should be discarded, it's more  
that for the foreseeable, we should concentrate on an HTTP Upgrade  
based solution.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 06 Aug 2010 10:29:29 +0200

On Fri, 06 Aug 2010 10:24:48 +0200, Dave Cridland <[email-masked]>  
wrote:
> As I recall, EKR made the point that TLS+NPN has yet to go through the  
> standards process, so would be problematic from that standpoint.
>
> that for the foreseeable, we should concentrate on an HTTP Upgrade based  
> solution.

I'm not sure who EKR is, but WebSocket itself is also not through the  
process. :-)

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 06 Aug 2010 01:52:17 -0700

On Aug 6, 2010, at 1:24 AM, Dave Cridland wrote:

> As I recall, EKR made the point that TLS+NPN has yet to go through the standards process, so would be problematic from that standpoint.
> 
> It's not that anyone's arguing that it should be discarded, it's more that for the foreseeable, we should concentrate on an HTTP Upgrade based solution.

If the requirements document is to be taken seriously, and the change the Chairs requested is made, then it would require that we discard the TLS+NPN solution since it doesn't involve an exchange of Upgrade headers at all. Indeed, this argument has been cited repeatedly as a reason the requirements document to not be too specific about the details.

Personally, I think this declaration of consensus is premature. Clearly a number of people disagree with the alleged consensus, and I believe we have serious technical reasons for this and are not just cranks. The statement from the chairs does not address these arguments at all.

Regards,
Maciej

---

From: Dave Cridland <[email-masked]>
Date: Fri, 06 Aug 2010 10:01:22 +0100

On Fri Aug  6 09:29:29 2010, Anne van Kesteren wrote:
> On Fri, 06 Aug 2010 10:24:48 +0200, Dave Cridland  
> <[email-masked]>  wrote:
>> It's not that anyone's arguing that it should be discarded, it's  
>> more  that for the foreseeable, we should concentrate on an HTTP  
>> Upgrade based  solution.
> 
> I'm not sure who EKR is, but WebSocket itself is also not through  
> the  process. :-)

Eric Rescorla. The guy who spoke reallyreallyfastwithnogaps. He's  
porbably the leading expert on TLS.

TLS+NPN has yet to enter the standards process, it's an individual  
contribution in draft status. We'd be looking at a delay to WS of at  
least a few months if we wanted to rely on this.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Aug 2010 11:48:33 +0200

Hi Maciej,

> Personally, I think this declaration of consensus is premature. Clearly a number of people disagree with the alleged consensus, and I believe we have serious technical reasons for this and are not…
If people want to do TLS+NPN, then NPN should be sent to TLS WG for 
review now[ish]. As other people pointed out, this might take a few 
months (with no guaranty of positive feedback from the TLS WG). But of 
course this shouldn't stop interested parties from progressing NPN 
document toward being an RFC.

---

From: Adam Barth <[email-masked]>
Date: Fri, 6 Aug 2010 10:05:25 -0700

On Fri, Aug 6, 2010 at 2:48 AM, Alexey Melnikov
<[email-masked]> wrote:
>> If the requirements document is to be taken seriously, and the change the
>> Chairs requested is made, then it would require that we discard the TLS+NPN
>> solution since it doesn't involve an exchange of Upgrade headers at all.
>> Indeed, this argument has been cited repeatedly as a reason the requirements
>> document to not be too specific about the details.
>>
>> Personally, I think this declaration of consensus is premature. Clearly a
>> number of people disagree with the alleged consensus, and I believe we have
>> serious technical reasons for this and are not just cranks. The statement
>> from the chairs does not address these arguments at all.
>
> If people want to do TLS+NPN, then NPN should be sent to TLS WG for review
> now[ish]. As other people pointed out, this might take a few months (with no
> guaranty of positive feedback from the TLS WG). But of course this shouldn't
> stop interested parties from progressing NPN document toward being an RFC.

I'll talk with Adam Langley about doing that.  I think NPN has value
beyond WebSockets, so it's worth putting through the standards process
even if we eventually decide to go another route with WebSockets.

Adam

---

From: Mike Belshe <[email-masked]>
Date: Fri, 6 Aug 2010 13:52:11 -0700

On Fri, Aug 6, 2010 at 1:29 AM, Anne van Kesteren <[email-masked]> wrote:

>> It's not that anyone's arguing that it should be discarded, it's more that
>> for the foreseeable, we should concentrate on an HTTP Upgrade based
>> solution.
>>
>

NPN even has implementations for OpenSSL, NSS, and Chrome available!  :-)  I
believe it has been submitted, but I'm not 100% sure:
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00

But we don't have to tie WebSockets agreement to NPN finalization.  The two
are independent.  The question at hand is whether WebSockets expects or
requires an independent handshake.  NPN is a simple example of one way where
out-of-band protocol negotiation can be done, alleviating the need for an
http upgrade.  If WebSockets requires a round-trip via the HTTP upgrade
mechanism and cannot exist without it (as declared by the chairs in this
email), then NPN, or any other similar mechanisms will likely not be useful.

The WebSockets team has everything it needs today (independent of NPN
formalization) to make a decision on this now.  NPN will be happening; it's
a simple and good idea with basically unanimous support.

I suspect that separating deployment questions for WebSocket is a good idea.
 The deployment over port 80, port 443, or another random port may all be
slightly different.  If we wish to support anything other than port 80 with
reasonable latency, I'd recommend not adding reliance on the Upgrade header
for handshaking.   But we can decide all this without waiting for formal
approval on NPN.

Mike

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 06 Aug 2010 23:17:20 +0200

just as clarification:

the declaration of consensus does not exclude TLS-nextprotoneg 
alternative, indeed the declaration states:

    "-/ The WG's focus is on leveraging existing HTTP-based
    infrastructure, although a future rechartering could
    investigate other alternatives./"

however a TLS handshake based on draft-agl-tls-nextprotoneg-00 at moment 
does not seem a reasonable one
for the next 4weeks plan neither so straightforward for the 6months plan.

However, I want encourage all the people that find value on 
TLS-nextprotoneg to discuss it in the TLS wg,
and also write down a draft on its usage as alternative handshake for 
WebSocket and submit it.

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Adam Barth <[email-masked]>
Date: Fri, 6 Aug 2010 14:52:29 -0700

On Fri, Aug 6, 2010 at 2:17 PM, Salvatore Loreto
<[email-masked]> wrote:
> just as clarification:
>
> the declaration of consensus does not exclude TLS-nextprotoneg alternative,
> indeed the declaration states:
>
> "- The WG's focus is on leveraging existing HTTP-based infrastructure,
> although a future rechartering could
> investigate other alternatives."

That makes it sound like we'd need a rechartering to consider using
TLS+NPN as the handshake.  The charter seems to say:

[[
  Although multiple protocols exist as starting points, backward
  compatibility with these protocols is not a requirement.
]]

Can you explain what parts of the charter rule out a websocket
handshake based on TLS?

> for the next 4weeks plan neither so straightforward for the 6months plan.

Why is that?  The TLS+NPN handshake is much simpler than the existing handshake.

> However, I want encourage all the people that find value on TLS-nextprotoneg
> to discuss it in the TLS wg,

Thanks for the encouragement, but I feel like you're railroading the
working group instead of building consensus.  The Tao of IETF says:

[[
Any decision made at a face-to-face meeting must also gain consensus
on the WG mailing list.
]]

When on this mailing list did we come to consensus about using an
HTTP-complaint handshake?  I certainly missed it.

Kind regards,
Adam

[1] http://www.ietf.org/tao.html#getting.things.done

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 7 Aug 2010 06:22:02 +0200

Hi Adam,

> Why is that?  The TLS+NPN handshake is much simpler than the existing handshake.

But it won't work everywhere due to port 443. However, designing with
that in mind should make us think how to rework the handshake so that
HTTP upgrade and TLS+NPN opening handshakes are the closest possible
one to the other and quickly converge to an established channel with
similar properties.

Regards,
Willy

---

From: Adam Barth <[email-masked]>
Date: Fri, 6 Aug 2010 21:26:58 -0700

> one to the other and quickly converge to an established channel with

I'm not claiming the working group has agreed to use TLS+NPN.  As far
as I can tell, the issue is still up for discussion.  I'd be happy to
discuss the technical differences further.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 7 Aug 2010 06:50:56 +0200

> discuss the technical differences further.

Agreed, and I too find that this could be useful. For instance, if some
of the actual data cannot be exchanged during the TLS+NPN handshake, we'll
have to exchange them later. The we should think whether it's a good idea
to exchange them during the HTTP handshake right now, and maybe only do
that when it saves round trips. Also, Gabriel wanted to have raw  WS over
any port, that could be covered by the same study.

In fact I suspect that large sites will like to be able to support both
HTTP and TLS at once to leave the choice to the user, as already is the
case for some webmails right now.

Willy

---

From: S Moonesamy <[email-masked]>
Date: Sat, 07 Aug 2010 04:11:08 -0700

Hi Adam,
>Can you explain what parts of the charter rule out a websocket

I'll quote the an extract of the draft minutes of the WG 
session.  This is more as a point of clarification and not as a decision.

   "Anne van Kesteren from Opera Software commented on a note sent by
    Ian Hickson about doing the handshake for TLS based on the TLS next
    protocol.  That seemed in conflict with this. Martin Thompson mentioned
    that there is no need to worry about this for now.  Ian Fette from
    Google asked whether this outlaws things like next protocol negotiation.
    Joe Hildebrand pointed out that is not the intent of the statement from
    the Chairs."

>Why is that?  The TLS+NPN handshake is much simpler than the 

The Area Director mentioned what needs to be done for TLS+NPN [1].

>Any decision made at a face-to-face meeting must also gain consensus

The statement is not based on the discussions at the face-to-face 
meeting; this is not a decision made at the face-to-face 
meeting.  The statement made by the WG Chairs is about Ticket #1 [2].

The WG Chair explained what would have to be done to address yours 
concerns [3].  draft-agl-tls-nextprotoneg is currently not a work 
item for the HyBi WG.  It will be difficult to convince the TLS WG 
that draft-agl-tls-nextprotoneg doesn't fall within their charter.

What would you propose as a way to move forward?

Regards,
S. Moonesamy
HyBi WG Secretary

1. http://www.ietf.org/mail-archive/web/hybi/current/msg03063.html
2. http://www.ietf.org/mail-archive/web/hybi/current/msg02955.html
3. http://www.ietf.org/mail-archive/web/hybi/current/msg03087.html

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Aug 2010 10:10:42 -0400

Since my name has been raised, let me try to elaborate a bit about the
situation with TLS+NPN
as I see it:

As background, the current draft of NGN (draft-agl-tls-nextprotoneg-00)
defines two
new code points (Section 5):

- A new TLS extension type.
- A new TLS handshake type.

The TLS standard (RFC 5246) defines the rules for the assignment of code
points in these
ranges. Extension types may be defined by "IETF Consensus" (this requires an
IETF LC).
Handshake types must be defined by "Standards Action" (this means a
standards
track RFC). This means that as a practical matter NGN as currently
constituted will
need to go through the TLS WG in order to reserve the code point through the
IETF
process. (To state the obvious, vendors can obviously grab a code point and
say
"that's NPN", but I'm assuming the intent is to actually follow the IETF
standards process
here.)

The status of NPN is that a draft exists, but there hasn't been a huge
amount of discussion
on the list, it has never been presented at a meeting, and it certainly
isn't a WG item.
(AFAIK the chairs have never been asked to take it on.) So, as Dave
suggests, even
if people in the TLS WG generally liked NPN as-is (and it's not clear that
that would be
the case, since protocols in general tend to change as they go through the
WG process)
it would be a matter of months at minimum before it was finished.

Best,
-Ekr

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 9 Aug 2010 01:15:47 +0200

I would think that a "focus on HTTP upgrade" would not preclude other
ways to establish websocket connections.

But if there is going to be ongoing concern about this, perhaps the
editors could proposed a phrase to make it clear that other mechanisms
are not precluded.

If that's not possible/sufficient - could we split this item so that
we can nail down the consensus on the HTTP compliance when we are on a
HTTP port vs the possibility of supporting non HTTP establishment.

cheers