Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-14.txt

From: [email-masked]
Date: Thu, 08 Sep 2011 12:11:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

	Title           : The WebSocket protocol
	Author(s)       : Ian Fette
                          Alexey Melnikov
	Filename        : draft-ietf-hybi-thewebsocketprotocol-14.txt
	Pages           : 77
	Date            : 2011-09-08

   The WebSocket protocol enables two-way communication between a client
   running untrusted code running in a controlled environment to a
   remote host that has opted-in to communications from that code.  The
   security model used for this is the Origin-based security model
   commonly used by Web browsers.  The protocol consists of an opening
   handshake followed by basic message framing, layered over TCP.  The
   goal of this technology is to provide a mechanism for browser-based
   applications that need two-way communication with servers that does
   not rely on opening multiple HTTP connections (e.g. using
   XMLHttpRequest or &lt;iframe&gt;s and long polling).

   Please send feedback to the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-14.txt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Sep 2011 20:27:33 +0100

>	Filename        : draft-ietf-hybi-thewebsocketprotocol-14.txt
The list of changes in this version is as follows:

Addressed multiple DISCUSS issues from IESG:
Text based on a note from Roy Fielding about use of port 80/443.
Clarified that header fields are case-insensitive (Stephen).
Fixed a wrong version number in one place (multiple people).
Clarified what is meant by "If the server supports encryption" (Stephen).
base64 data can be empty. (Pete)
Clarified how multiple versions of WebSocket can be supported. (Stephen)
Clarified that frame payload lenght must use minimal encoding. (Stephen)
Allow frame-rsv* to be 1 in the ABNF (if negotiated via extensions). (Sean)
Clarified that multiplexing is not defined in this document.
Various clarifications about Pings (data is allowed, etc.)
Additional security consideration about cache poisoning when masking is 
not used. (Russ/GenArt).
Expanded text about denial of service from receiving big frames or long 
sequences of small frames. (Russ/GenArt).
MUST support TLS. Better cipher recommendations. (Stephen)
Clarified that no security properties are expected from SHA-1.
Additionally:
Allow to use quoted-string in extension-param (still restricted to ASCII).
Extended meaning of 1007 close status code (as per WG consensus).
Addressed some Comments from Pete Resnick (avoid use of "conformance"), 
Robert Sparks and Wesley.
Reduced version of the text about history of masking.
Clarified that masking key is randomly generated in each frame.
Clarified that some header fields can appear multiple times. (per WG 
discussion)
Fixed several typos.

Please note that this version doesn't address all DISCUSS comments 
(blocking comments) from IESG and I also have a list of some other 
remaining changes (both non blocking comments from IESG and some 
comments from the WG.) So there would be a version -15 to address these.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Sep 2011 13:45:27 -0600

On 9/8/11 1:27 PM, Alexey Melnikov wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the BiDirectional or
>> Server-Initiated HTTP Working Group of the IETF.
>>

Thanks to the editors for the quick turnaround!

> The list of changes in this version is as follows:

And a full diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-14

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 02:33:34 -0700

"""
10.4.  Implementation-Specific Limits

   Implementations MUST impose implementation-specific limits on
   otherwise unconstrained inputs, e.g. to prevent denial of service
   attacks, to guard against running out of memory, or to work around
   platform-specific limitations.  In particular, a malicious endpoint
   can try to exhaust its peer memory by sending either a single big
   frame (e.g. of size 2**60), or by sending a long stream of small
   frames which are a part of a fragmented message.  In order to protect
   from this implementations SHOULD impose limit on frame sizes and the
   total message size after reassembly from multiple frames.
"""

This text seems to suggest that

a) sending large frames or large messages is seen as a DoS attack and discouraged
b) all implementations would have internal limits wrt to frame/message size

IMHO, this is misleading.

Implementations with a frame-based API likely don't have limits regarding
total message size. Implementations with a streaming API likely don't have
limits regarding frame size (besides the protocol imposed limit of 2 ^63 octets).

Why are those implementations required to impose limits? Does not make sense.

Also, sending large frames/messages is not a DoS attack, but a valid use of WS.
When the receiving peer is incapable of processing the frame/message, it
should protect itself, but the sender isn't the one to blame for those limits.

I'd like to suggest something more neutral:

"""
Implementations which have implementation- and/or platform-specific
limitations regarding the frame size or total message size after reassembly
from multiple frames MUST protect against exceeding those limits.

Exceeding implementation/platform specific limits on otherwise unconstrained
inputs could be used by a malicous peer to mount a DoS attack or exhaust
the peers memory.
"""

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 02:49:08 -0700

"""
10.6.  Connection confidentiality and integrity

   Communications confidentiality and integrity is provided by running
   the WebSocket protocol over TLS (wss URIs).  WebSocket
   implementations MUST support TLS, and SHOULD employ it when
   communicating with their peers.
"""

Why MUST?

For example, TLS does not provide end-to-end confidentiality when
WebSockets used for communicating between client peers, and
the WS server is only there to mediate e.g. publish/subscribe messages.

In this case, confidentiality/integrity can be accomplished by encrypting
the payload of the messages, but without encrypting the point-to-point
transports between the clients to the server. Encrypting the transport
when the payload is already encrypted does not make sense in this
scenario.

I'd like to suggest:

"""
When point-to-point communication confidentiality and integrity is
desired and sufficient, the implementation SHOULD use TLS.
"""

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 06:52:10 -0400

Short answer: BCP 61, Section 7.
<http://tools.ietf.org/html/bcp61#section-7>

On Sep 12, 2011, at 5:49 AM, Tobias Oberstein wrote:

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 06:58:35 -0400

> a) sending large frames or large messages is seen as a DoS attack and discouraged

It isn't always (neither is sending a GET request as a frame payload), but it can be used that way.

> b) all implementations would have internal limits wrt to frame/message size

All implementations *do*.  Storage is finite.

> limits regarding frame size (besides the protocol imposed limit of 2 ^63 octets).

In that case, the burden is just passed to the recipient of the stream.  I would be OK with text calling this out as an exception.

> inputs could be used by a malicous peer to mount a DoS attack or exhaust

The qualification in the first sentence is not really meaningful -- every host has finite storage.  If my laptop were at the office on a nice fat pipe, you could fill the hard disk in a couple of hours; servers typically operate on much thinner margins.

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 04:02:41 -0700

> All implementations *do*.  Storage is finite.

No. This assumes you would need to store the received data, which might
not be necessary.

Here is an example of a WS server that computes a SHA256 over data
received, sending a digest update for every 1M octets received.

It can run forever in constant memory.

http://www.tavendo.de/autobahn/tutorial/streaming.html#streaming

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 04:13:02 -0700

> <http://tools.ietf.org/html/bcp61#section-7>

I'm not sure, are you pointing to 

"   However security must be a MUST IMPLEMENT so that end users will have
   the option of enabling it when the situation calls for it.
"?

This does not say TLS must be used, but only that "security" is mandatory.

TLS provides point-to-point security, but not end-to-end, the latter
providing a higher level of confidentiality.

So, when end-to-end security is desired by a user in some scenario,
an implementation could provide a message payload encryption scheme
and BCP 61, Section 7 would be fulfilled without having TLS implemented.

What about

"""
Point-to-point communications confidentiality and integrity is provided by running
the WebSocket protocol over TLS (wss URIs).

WebSocket  implementations MUST support TLS, and SHOULD employ it when
communicating with their peers, unless a stronger form of security scheme
like end-to-end encryption is in place.
"""

> > WebSockets used for communicating between client peers, and the WS
> > server is only there to mediate e.g. publish/subscribe messages.
> >
> > In this case, confidentiality/integrity can be accomplished by
> > encrypting the payload of the messages, but without encrypting the
> > point-to-point transports between the clients to the server.
> > Encrypting the transport when the payload is already encrypted does
> > not make sense in this scenario.
> >
> > I'd like to suggest:
> >
> > """

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 10:04:42 -0600

>>> desired and sufficient, the implementation SHOULD use TLS.

WebSocket *is* a point-to-point protocol. For a WebSocket client, the
peer is the server; for the WebSocket server, the peer is the server.
Mandating support for TLS (and encouraging use of TLS) seems quite
appropriate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Sep 2011 18:08:45 +0200

> Mandating support for TLS (and encouraging use of TLS) seems quite

And where are now the famous "intermediaries"?
There could be a WebSocket intermediary that speaks TLS with the
client and plain WS with the server. Same concept as in HTTP, SIP and
other protocols.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 10:28:01 -0600

> client and plain WS with the server. Same concept as in HTTP, SIP and

Even if there is an intermediary (proxy or caching server etc.) an
entity can set up a TLS-encrypted connection to its peer.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Sep 2011 18:29:48 +0200

> entity can set up a TLS-encrypted connection to its peer.

That's not true in HTTP. Is it in WS?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 13:01:12 -0400

That's what CONNECT is for, right?  It turns a link through a proxy into a point-to-point link.

In any case, trying to distinguish "point-to-point" from "end-to-end" protocols in the Internet is pretty futile.  If you want to reductio the absurdum here, nothing that runs over IP is "point-to-point", since there are routers involved.  For that matter, you could make the same argument with Ethernet and switches.  And on the other side of the stack, you can run IP over anything, e.g.:
<http://tools.ietf.org/html/rfc3093>

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 13:01:40 -0400

> like end-to-end encryption is in place.

-1

This text doesn't change anything meaningful.  The current "MUST support / SHOULD employ" is entirely standard for compliance with BCP 61 and sufficiently describes the requirements in this case.

--Richard

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 11:03:06 -0600

On 9/12/11 11:01 AM, Richard L. Barnes wrote:
>> "   However security must be a MUST IMPLEMENT so that end users
>> will have the option of enabling it when the situation calls for
>> it. "?
>> 
>> TLS provides point-to-point security, but not end-to-end, the
>> latter providing a higher level of confidentiality.
>> 
>> So, when end-to-end security is desired by a user in some
>> scenario, an implementation could provide a message payload
>> encryption scheme and BCP 61, Section 7 would be fulfilled without
>> having TLS implemented.
>> 
>> What about
>> 
>> """ Point-to-point communications confidentiality and integrity is
>> provided by running the WebSocket protocol over TLS (wss URIs).
>> 
>> WebSocket  implementations MUST support TLS, and SHOULD employ it
>> when communicating with their peers, unless a stronger form of
>> security scheme like end-to-end encryption is in place. """
> 
> -1
> 
> This text doesn't change anything meaningful.  The current "MUST
> support / SHOULD employ" is entirely standard for compliance with BCP
> 61 and sufficiently describes the requirements in this case.

Agreed (with my AD hat on).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 10:15:40 -0700

> Even if there is an intermediary (proxy or caching server etc.) an entity can
> set up a TLS-encrypted connection to its peer.

A browser (peer 1) that wants to have confidential communication with
a server (peer 2) cannot rely on TLS for that under all scenarios.

I have seen at least one corporate network where the browser was deliberately
"poisened" with a root certificate of some transparent proxy that would unwrap
TLS connections and generate pseudo-certificates for the real target server CN
issued with the proxy CA and trusted by the browser.

The proxy can read all traffic. There where all kinds of "issues": i.e. employees
doing private banking at work over Web, where the network admins can
read the traffic etcetc. In the end, they then setup a "whitelist" again for HTTPS
targets that were not sniffed.

Anyway: TLS for HTTPS nowerdays does not provide confidentiality even for
2 WS peers.

===

I still don't get why TLS support is MUST,  but will shut up now, since you already
finished the discussion as AD.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Sep 2011 19:21:50 +0200

2011/9/12 Richard L. Barnes <[email-masked]>:
> In any case, trying to distinguish "point-to-point" from "end-to-end" protocols in the Internet is pretty futile.  If you want to reductio the absurdum here, nothing that runs over IP is "point-to-point", since there are routers involved.  For that matter, you could make the same argument with Ethernet and switches

Nobody is speaking about IP, but about TLS which runs *on top of TCP*.
A TCP communication is *end-to-end* even if there are 100000 IP
routers in the path. Is it so hard to understand?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 20:38:33 +0200

> issued with the proxy CA and trusted by the browser.

That's quite common nowadays unfortunately.

> targets that were not sniffed.

I agree with you. We've had this discussion in the past about schools. I've
had to work with schools where content filtering is mandatory to ensure that
children don't visit inappropriate sites. In such environments, security is
brough by *not encrypting*. Encryption is a means of increasing security by
increasing confidentiality and integrity, and sometimes authentication, it
is not a solution to all security issues and sometimes it's worse.

That's the reason why people who install IDS on their network always decipher
the traffic on reverse proxies and analyse the contents *after* the traffic
has been deciphered. Some would consider that clear traffic is less security
than encrypted traffic, while it's the opposite when you want to validate the
contents in order to keep a certain level of security.

Also, most WS implementations will rely on application servers which will
either hide the TLS work, or even delegate it to another component, which
in practice results in the WS implementer not being aware of TLS at all on
the server side, so making TLS a requirement of the implementation will
sometimes be out of context. On many web architectures nowadays, the end
server does no SSL/TLS at all.

TLS is a feature inserted between the transport layer and HTTP, and WS runs
on top of HTTP, so in this context, WS is not concerned by this TLS issue.
In fact, what will probably happen is that a number of implementations won't
care at all about this requirement because they'll think "hey I don't care,
it's not my concern, it's the underlying server's" and the point will
eventually be removed from a newer version. In fact, it's comparable to
saying that an HTTP implementation must implement TLS. We all know many
places where this is not true and even a number of HTTP implementations
that do not support TLS at all.

> Anyway: TLS for HTTPS nowerdays does not provide confidentiality even for

I would say that it still does provided that the user is extremely careful
and checks all the certificate chain. We obviously all do that everyday,
aren't we :-)

> finished the discussion as AD.

I disagree with you Tobias. An AD, like everyone else, is someone who
could change his mind when provided with enough convincing elements or
facts. Possibly that till this point Peter only considered confidentiality
as the security feature for BCP61#7, and will also consider that being
able to prevent encryption from being used is an equally important security
feature in some environments.

Regards,
Willy

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 15:25:00 -0400

This is wildly off-topic.  TLS MitM attacks by enterprise firewalls are possible because the clients are configured with additional trust anchors.  The selection of trust anchors is and always has been a matter for client configuration, not standards.  And that's the situation for every security protocol, not just TLS.

--Richard

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 22:02:19 +0200

> This is wildly off-topic.  TLS MitM attacks by enterprise firewalls are possible because the clients are configured with additional trust anchors.  The selection of trust anchors is and always has…

Granted, but the argument for making TLS mandatory was the perceived
increased security, which is contrary to the other points raised below
in some environments. The point you cite above was just one example
that was given by Tobias to say that TLS does not solve everything.

Regards,
Willy

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 13:07:04 -0700

> This is wildly off-topic.  TLS MitM attacks by enterprise firewalls are
> possible because the clients are configured with additional trust anchors.
> The selection of trust anchors is and always has been a matter for client
> configuration, not standards.  And that's the situation for every security
> protocol, not just TLS.

Richard,

with all due respect, I think it's not off topic. Please let me give
2 examples.

1.
A JS browser app communicating with a known server that it wants to
trust cannot rely on TLS for confidentiality. When the user of the
browser does not check installed root certs, there can be MITM. When
the user checks, and some MITM cert is installed, it's likely because
of enterprise network policy, in which case the user usually has no
way of deinstalling the cert.

However, one can implement PKI in JS without using the browser cert
store. Still, the server public key would be needed. This key can be
embedded in the JS script hosted by the server. That way, a enterprise
inspection system will usually not find/tamper with it. It could, in
principle. To get around this, the JS can use i.e. the new File API
and ask the user to select the server public key from i.e. his USB
storage device, which isn't under control of browser/corporate admins.

2.
A JS chat app wants to do chatting with other instances of the chat
app with confidentiality, not only wrt to enterprise sniffers, but
also wrt to the WS server hosting the chat pubsub exchange.

The JS app can encrypt the payload itself (implement the encryption
in JS) and communicate using unencrypted WS (using the browser supplied
WS implementation), while providing perfect end-to-end message
confidentiality. Note that "end-to-end" is not protocol related term, but
information confidentiality from user perspective related.

==

With both examples TLS does not allow for uncompromised confidentiality.
Nevertheless it can be provided without having the transport encrypted
at all.

I really think requiring a specific transport encryption technology (TLS)
in the WS spec in a language that justifies that by claiming that this
solves "confidentiality and integrity" (without explaining restrictions)
is misleading.

Regards,
Tobias

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 16:13:43 -0400

It's not the job of the IETF to make sure that users don't install bad trust anchors.
--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2011 13:19:30 -0700

I don't really think this is a sensible way to think about the problem.

Yes, it's true that TLS and HTTPS are imperfect, and in particular that there
are issues with the root list. However, (1)to suggest that because
those issues exist that somehow HTTPS doesn't do anything simply isn't
correct. (2) Since the entire security infrastructure of the Web depends
on HTTPS, if you can't trust the browser/HTTPS infrastructure you're
in serious trouble.

In particular, you suggest that one can compensate for deficiencies
in the browser trust enforcement by executing checks in the JS, but
the only thing that assures correctness of the JS is the fact that
it's downloaded over HTTPS, which is enforced by the browser and
the JS cannot check itself (because one must first be sure that the
JS is correct.) So, you're back to the security of HTTPS.

Obviously, I don't think it's bad to have the security considerations be
clear on the limitations of the environment (though to a great extent
these are generic to anything over HTTPS). Perhaps it would be useful
if you suggested some text....

-Ekr

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 13:33:57 -0700

> JS is correct.) So, you're back to the security of HTTPS.

If the JS comes over the network, then yes, even if the public key
is selected by the user from USB drive, it could still be tampered.

If the JS comes from a locally installed Web widget, which is installed
locally, from a signed package, using the OS package installer, with
the JS widget running in the browser, then the OS package installer
trust chain matters. That could be tampered of course as well by
the corporate admins.

If the JS is started from files residing on the USB stick of the user,
tampering with the JS gets even harder.

I'm not saying TLS is bad. To the contrary. But I am saying that
TLS is not a panacea, and that saying a WS implementation that does
not implement TLS in non-conforming is -- strange.
 
> if you suggested some text....

But I did suggest text (other posting) ..

"""

>>>>> TLS connections and generate pseudo-certificates for the real target
>>>>> server
>>>>> CN
>>>>> read the traffic etcetc. In the end, they then setup a "whitelist" again
>>>>> for
>>>>> HTTPS
>>>>> I still don't get why TLS support is MUST,  but will shut up now, since
>>>>> you
>>>>> already

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2011 13:49:54 -0700

> tampering with the JS gets even harder.

These cases are so uncommon compared to the Web case (and since
the whole purpose of WS is to allow Web apps to escape the ordinary
browser sandbox that's the important case regardless), that this basically
seems non-relevant.

> not implement TLS in non-conforming is -- strange.

I don't see why. We have the requirement for TLS stapled all over IETF
protocols. To give one examples off the top of my head, SYSLOG
(RFC 5424) requires TLS.

> desired and sufficient, the implementation SHOULD use TLS.

That's not an explanation of the limitations, it's a different normative
requirement. Not the same thing.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 23:05:29 +0200

Hi Eric,

> protocols. To give one examples off the top of my head, SYSLOG

Interesting. Considering that something like 100%-epsilon of the world's
syslog emitters and receivers don't support TCP and that something like
1% of them are TLS-capable, this seems to suggest that whatever is written
in this section with a MUST requirement is still left to the implementer's
appreciation. It's a bit counter-productive I think to add requirements
that we know are not followed because it only incites implementations to
be non-compliant on a number of other points (ie: MUST are then understood
as SHOULD).

I'm personally all for a big SHOULD, but I'm fairly certain that some
implementations won't care at all because they'll delegate the TLS job to
a component that is said to be available somewhere in their infrastructure
and that the developers don't need to have knowledge about.

Regards,
Willy

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 14:05:52 -0700

> if you suggested some text....

Whenever point-to-point communication confidentiality and integrity
between WebSockets peers is required and sufficient, TLS MUST be
used.

When using TLS the confidentiality and integrity of communication
depends on the integrity and trust put into the PKI trust chain on both
peers. With browsers, certain security products deployed in enterprise
networks might alter the trust chain (the browser certificate store)
without the user taking notice and/or without the user being able to
control. The altered browser certificate store might allow the
security intermediaries to break communication confidentiality and
integrity.

TLS provides point-to-point confidentiality and integrity. TLS does
not provide end-to-end confidentiality and integrity. For example,
two WebSocket peers (i.e. browser instances) that communicate via
a common well-known peer (i.e. a server mediating messages between
the client peers) can not communicate confidentially, since the
mediating server acts as a man-in-the-middle, terminating both
TLS connections of both client peers.

When end-to-end message confidentiality and integrity is desired,
a different technology, for example S/MIME applied to WebSockets
message payloads is needed.

A WebSockets implementation that implements an end-to-end message
security scheme MAY communicate without a transport encryption
(TLS) being in place, since an additional transport based security
is unneeded in this case to maintain the message integrity and
confidentiality, and a double encryption increases implementation
complexity and run-time resource consumption without increasing
security.

An implementation that only operates in contexts and with peers
that either require no confidentiality and integrity (neither
point-to-point nor end-to-end) or requires end-to-end confidentiality
and integrity (and implements an appropriate security regime),
the implementation MAY opt to not implement TLS.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2011 14:13:22 -0700

> be non-compliant on a number of other points (ie: MUST are then understood

Well, this is not the case for HTTPS, where the vast majority of HTTP instances
do in fact support HTTPS.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2011 14:23:22 -0700

> between WebSockets peers is required and sufficient, TLS MUST be

I'm fine with this, but actually I think it's stronger than necessary.
If you had
IPsec, for instance, that might be fine.

> not provide end-to-end confidentiality and integrity.

This may or may not be true. It depends what the ends are.

> For example,

This and the previous paragraph seem extremely problematic for the
reasons I indicated previously. I.e., that it is very unlikely that there
will be a source of JavaScript that it is not subject to attack by
someone who is able to forge HTTPS. This isn't to say that it's
not of value to have security (e.g., via DOMCrypt) where the JS
is supplied by someone you trust but yet you wish them not to
have access to the plaintext, but this is a much more nuanced
issue  than you are presenting here.

Moreover, in many such cases you would *still* want HTTPS to
protect you from the network attackers, with the object security
being designed to protect you from retroactive/passive attack from
the Web server(s).

> the implementation MAY opt to not implement TLS.

No, I disagree with this, especially the first part.

-Ekr

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Sep 2011 23:29:33 +0200

On 2011-09-12 23:13, Eric Rescorla wrote:
> On Mon, Sep 12, 2011 at 2:05 PM, Willy Tarreau<[email-masked]>  wrote:
>> Hi Eric,
>>

Although there is no requirement in HTTP to support it.

IMHO this indicates that YELLING at the reader to do something they 
don't want to do doesn't help. What helps is *explaining* why something 
needs to be done.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 23:30:19 +0200

> do in fact support HTTPS.

It depends if you count on deployed server base or only the most visited ones.
Many servers such as mini-httpd (thttpd derivative) or equivalent that are
found in a bunch of off-the-shelf network devices don't implement it at all,
sometimes because of resource limitation, and sometimes there's no need for it.
After all, what's the point of using https to connect to my DSL modem, I
don't have its certificate, and it may only be spoofed by someone at home.

Here with WS we're at a different level. I'm convinced that most deployment
will enable TLS from the user's point of view, but that at the same time the
TLS work will be offloaded (as it is for HTTPS nowadays). And that's the
point I'm insisting on : the developer will only get a connection with a
clear-text WS handshake, sometimes over a local unix socket connected to
its application server, and will have no knowledge of transport protocols,
he will only see a handshake and be able to exchange frames. The transport
will not be accessible at all. That's why I find it troubling to ask these
developers to support TLS, it does not affect their code. Someone may even
connect in SSLv2 to the HTTPS server and the WS implementation is not aware
of it.

Maybe we should just find a different wording, probably something along
"implementations must be compatible with either HTTP or HTTPS as the
underlying transport protocol" or I don't know, but something which
indicates that changing the lower layer must be possible if needed.

But the point is that both TCP and TLS are often invisible from the
implementation (at least on the server side, maybe on the client it's
more visible).

Regards,
Willy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2011 14:33:04 -0700

> It depends if you count on deployed server base or only the most visited ones.

The vast majority of instances are browsers, essentially all of which
support HTTPS.

> don't have its certificate, and it may only be spoofed by someone at home.

I don't know about your modem, but my Linksys WRT54G sure supports
HTTPS.

> connect in SSLv2 to the HTTPS server and the WS implementation is not aware

I'd be satisfied with a requirement that clients MUST support it.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 23:38:17 +0200

> IPsec, for instance, that might be fine.

Good point. Maybe something more open :

  Unless confidentiality and integrity are coverred by other means
  with an acceptable risk, TLS MUST be used.

This allows my weather station to send me the temperature in clear text
and it also allows phone calls to be sent in clear text over an IPsec
channel.

Regards,
Willy

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 14:50:42 -0700

> IPsec, for instance, that might be fine.

Yes, even better. Why require transport encryption being via TLS
when IPSec is in place:

"Whenever point-to-point communication confidentiality and integrity
between WebSockets peers is required and sufficient, either TLS or
IPSec MUST be used."

> This may or may not be true. It depends what the ends are.

"TLS does not provide end-to-end message payload confidentiality and
integrity from an application perspective."

"For example .."

"Another example with only two involved application instances would
be when the TLS connection established between the two WebSocket
peers is terminated by an intermediary before the sending/receiving
peer, in which case the TLS terminating intermediary breaks the
message confidentiality from an application perspective."

> will be a source of JavaScript that it is not subject to attack by

The situation today is obviously as you describe. Whether the browser
in the future will develop into a generic application run-time
environment and locally installed Web widgets become widely used -
who knows. Might be, might not.

However, the paragraph in the spec currently reads

"""

This includes _any_ WS implementation, browsers, non-browser clients
and servers. All those are required to implement TLS, otherwise they
are non-conforming.

> No, I disagree with this, especially the first part.

Implementing WS on a 8-bit MCU might be possible. TLS might be not.
Neither S/MIME variant. It might be both impossible (very hard) and not
necessary (for application). The implementation will have to say
"non-conforming". :(

I think in practical terms, whatever the spec requires, some implementations
will not care anyway .. and personally, a WS implementation that fully
conforms to the spec but does not implement TLS, for well laid out reasons
- I'm fine with that.

I'm with Julian on this: explaining stuff in the spec helps more than
bullying ..

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 14:58:21 -0700

> This allows my weather station to send me the temperature in clear text

nice example. why not have WS in little sensor boards, whatever .. a machine
web. it's a hard tax to require all those little things to implement TLS
just for the sake of it, even when they never want to use it (or have the
beef to run it) ..

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 16:08:19 -0600

> just for the sake of it, even when they never want to use it (or have the

Come on, folks, this is not the CORE WG. Let's not open up a huge debate
about small-footprint devices if we really don't need to.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 13 Sep 2011 00:53:40 +0200

> don't want to do doesn't help. What helps is *explaining* why something 

100% agreed Julian, and we've had this issue with a number of other points
in the past (masking, choice of randoms, etc...) for which the casual reader
will generally not guess the initial reason and might still decide not to
perfectly respect the spec because the cost is high for something he does
not understand the consequences.

In my opinion, when a MUST is associated with something that might be
expensive or represent a certain complexity to implement, it should be
associated with an explanation, even if that makes the spec larger. That
would have saved a number of questions on masking and on Sec- headers
for instance.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 13 Sep 2011 09:00:57 +1000

FWIW I think that TLS  is a SHOULD or MAY level thing.   Most
implementations will support it because they think it is a good idea
anyway.  I don't see the point of saying to the few implementations
that might have a reason to not to have TLS that they are non
compliant with the spec.

If we say MUST, there will still be implementations that don't;  If we
say MAY, it will still be supported on the vast majority of
implementations;  so the former feels a little like charging at
windmills.

cheers

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 13 Sep 2011 01:04:21 +0200

> about small-footprint devices if we really don't need to.

It's not much about opening up this debate, Peter (and I don't have a
weather station), it's about explaining that there are situations where
implementations will find it legitimate to violate a MUST in the spec.
Usually, MUST are used for protocol compatibility and here we're using
this to force a user to do something he probably does not want. It's
better if we can ensure that implementaters don't have to select the
list of MUSTs they will respect. Here we're in front of an example
that could be softened a bit. Eric already explained that what he
thinks matters the most are browsers and I tend to agree with this view.
Maybe in the future we'll see HTTP proxies which know how to deal with
requests such as "GET wss://xxx" and in this case some places will prefer
to have cleartext between the browser and the proxy and the proxy will
handle TLS itself. You see, there are many ways to get the security
right for a given risk to cover, but by trying to force users to blindly
apply something that a) does not necessarily apply to them, and b) they
don't need nor understand, we risk facing much lower quality implementation
"just because it's mandatory". This reminds me of servers which were
distributed with https enabled and a self-certificate that was generated
upon first boot. Clueless admins did not even know that 443 was opened
because they only used 80 and they did nothing to protect 443.

Best Regards,
Willy

---

From: SM <[email-masked]>
Date: Mon, 12 Sep 2011 16:29:53 -0700

Hi Tobias,
>This does not say TLS must be used, but only that "security" is mandatory.

You left out the last paragraph:

   "However security must be a MUST IMPLEMENT so that end users will have
    the option of enabling it when the situation calls for it."

This does not mean that TLS must be used.  The point here is to have 
the code shipped with TLS support.  The user then has the choice to 
enable it if he/she wishes.  Nothing in there says that the user must use TLS.

Regards,
-sm

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 21:02:05 -0400

> and it also allows phone calls to be sent in clear text over an IPsec

And now you've demonstrated exactly why that wording is useless.  "SHOULD use" captures all of the exceptions you're pointing out.

--Richard

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 19:58:35 -0600

> because they only used 80 and they did nothing to protect 443.

Willy, please take a look at Section 10 of draft-ietf-core-coap, which
is being produced in the CORE WG:

http://tools.ietf.org/html/draft-ietf-core-coap-07#section-10

Yes, it's possible to specify a mix of TLS and IPsec, but it's more
complicated to do so. Furthermore, it doesn't seem necessary because
unlike the CORE WG we're not explicitly designing for constrained
networks or small-footprint devices.

Even if we were to go down that path, it would probably require fairly
major changes to the spec at this point, after it has undergone working
group last call, IETF last call, Security Directorate review, and IESG
review. Depending on the scope of those changes, we might be looking at
another round of last calls and reviews, which would likely lead to
significant delays in publication. Is that worth it?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 13 Sep 2011 08:25:26 +0200

> http://tools.ietf.org/html/draft-ietf-core-coap-07#section-10

I've quickly gone over it, looks like an interesting document, I didn't
know it. I'll take a deeper look.

> networks or small-footprint devices.

It's not only a matter of small-footprint, it's a matter of general
use. At the other end, large systems dealing with very large amounts
of concurrent connections will not implement TLS either and will
delegate it to another component. We all know that we only want it
so that communications between a browser and a server can be encrypted
over *the internet*, without any specific requirement in the local
areas (eg: client-side enterprise network might remain clear as well
the server-side). As Eric pointed it out, it seems legititmate to
ask that *browsers* implement TLS, it's a very low cost for them,
they all have it already. But why impose this to a category of
products we don't know ? Maybe some network backup products will
switch to use WS at one point because it's easier to reach remote
locations than with their proprietary protocol. And those products
will send digitally signed and encrypted data anyway so using TLS
on the transport layer brings no benefit there.

> significant delays in publication. Is that worth it?

I don't think we'd change anything, because (unless I'm mistaken), this
MUST requirement suddenly appeared in the last iteration of the draft.
I think that the SHOULD wording covers all aspects and all uses.

BCP61 says that security is a MUST, not TLS. Security is already there
by design. We have the the handshakre, random keys, masking, etc... all
that is required to ensure safe operation. The protocol support wss
scheme URIs for when the client wants a TLS layer below it. But in my
opinion, nothing says that everyone must implement TLS.

Last, if I can repeat myself, the WS implementation will not even be
concerned by the transport mode. The layering will often look something
like this :

          +----------------+  \
          | WS application |   |
          +-------+--------+  /
                  |           >  WS implementations
                  v           \
          +-------+--------+   |
          |  WS framework  |   |
          +-------+--------+  /
                  |
                  v
          +----------------+
          | HTTP framework |
          +---+--------+---+
              |        |
              |        v
              |     +-----+
              |     | TLS |
              |     +--+--+
              |        |
              v        v
          +---------------+
          | Socket layer  |
          +---------------+

The two upper layers *are* WS implementations, and none of them is aware
of TLS. This can be application code shipped as a plugin for a browser,
or a dynamically loadable library providing an application on the server
side, and none of them even sees TLS references anywhere. This is even
more visible for applications which will rely on the browser's or the
application server's WS framework. However, I find it legitimate to say
that the whole component should implement TLS, and we could add something
to say that the WS implementations above must be unaffected by the use
of TLS below them.

And in other environments, we'll surely see implementations like this
appear for a variety of usages :

          +----------------+
          | WS application |
          +---+--------+---+
              |        |
              |        v
              |     +-----+
              |     | TLS |
              |     +--+--+
              |        |
              v        v
          +---------------+
          | Socket layer  |
          +---------------+

And some like this (which was the original goal in this WG BTW, with
Hixie's goal of WS for everyone) :

          +----------------+
          | WS application |
          +-------+--------+
                  |
                  v
          +---------------+
          | Socket layer  |
          +---------------+

What made HTTP succeed is that it is very versatile. It's beeing used
for webservices, or as a transport layer for databases. WS surely is
more appropriate for such usages with much lower overhead and latency,
it is very likely that with time it will supersede HTTP for some of
these usages. And it's very likely that many such implementations will
not implement TLS and will deliberately violate the spec. The SHOULD
avoids this issue. We could equally say that clients that are TLS
capable MUST implement TLS, but that's basically a going back to a
SHOULD.

Best regards,
Willy

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 23:45:52 -0700

> enable it if he/she wishes.  Nothing in there says that the user must use TLS.

Huhh? Your quote is exactly the same what I quoted .. puzzled.

Anyway, the BCP does seem to say:

1. implementing _security_ is a MUST
2. _using_ security is MAY

It does not seem to say the security of 1. MUST be TLS.

If I ship with IPsec, but without TLS, that seems to fit the BCP.

If I ship with S/MIME-applied-to-WS, but without IPsec or TLS, that should
be fine in the BCP sense also. I did ship security.

---

From: SM <[email-masked]>
Date: Tue, 13 Sep 2011 00:52:21 -0700

Hi Tobias,
>Huhh? Your quote is exactly the same what I quoted .. puzzled.

Sorry, I missed it.

>1. implementing _security_ is a MUST

Yes.

>2. _using_ security is MAY

I would not use MAY in this context.  I agree with you on the idea.

>It does not seem to say the security of 1. MUST be TLS.

No.

>be fine in the BCP sense also. I did ship security.

Yes, but everybody knows that's hand-waving.

For what it is worth, it is important to understand the context in 
which that BCP was written.  I don't think that discussing about the 
BCP will convince anyone to review their position.  I don't have a 
strong position about all this.

Regards,
-sm

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 13 Sep 2011 18:03:04 +1000

>From a practical point of view, that makes compliance testing
difficult, because you don't know if a server has TLS implemented and
not disabled.  Also way is the difference between disabling security
with configuration, or by removing the implementation?  Would that
mean that servers that shipped with TLS as an optional extra would not
be able to claim compliance unless the TLS version was purchased?

I also think that saying we must implement TLS is rather pointless.
Does that mean an implementation that only supports the null cipher or
16 bit keys will be considered secure? Or one with a self signed
certificate?

Saying MUST to TLS is pointless unless you go on the say MUST support
cipher X,Y,Z, and MUST support certain key lengths etc.    Without
saying all that, you have not improved interoperability or security at
all.  In fact you have probably harmed security because servers will
ship with self signed certificates turned on so they can say they are
spec compliant and these will stupidly get deployed into production.

regards

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 13 Sep 2011 01:33:18 -0700

> From a practical point of view, that makes compliance testing difficult,
> because you don't know if a server has TLS implemented and not disabled.
> Also way is the difference between disabling security with configuration, or
> by removing the implementation?  Would that mean that servers that
> shipped with TLS as an optional extra would not be able to claim compliance
> unless the TLS version was purchased?
> 
> 16 bit keys will be considered secure? Or one with a self signed certificate?
> 
> saying all that, you have not improved interoperability or security at all.  In
> fact you have probably harmed security because servers will ship with self
> signed certificates turned on so they can say they are spec compliant and
> these will stupidly get deployed into production.

Hi Greg, I absolutely agree with all you say above.

FWIW, my opinion:

With WS, browsers MUST implement TLS, but other WS
implementations MAY.

If an implementation chooses to implement a (any at all) transport level
security scheme, that SHOULD be TLS or IPsec.

The latter is: don't reinvent the wheel.

Whether a WS implementation (other than browsers) implements TLS
should not be a criteria for WS protocol conformance.

---

From: "Alexander Philippou" <[email-masked]>
Date: Tue, 13 Sep 2011 12:56:34 +0300

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Oberstein
> 

I agree, I'd just like to refine a bit your point.

While WS libraries targeting non-browser clients might implement TLS, vendors selling them as s/w components to 3rd party developers/deployers might wish to offer them both with and without TLS support. The latter would be for developers/deployers who are interested in reducing code size and avoiding export restrictions (and, obviously, don't require the WS library to provide transport security). As BCP 61 states:

   As mentioned earlier, some protocols may be deployed in secure
   enclaves for which security isn't an issue and security protocol
   processing may add a significant performance degradation.  Therefore
   it is completely reasonable for security features to be an option
   that the end user of the protocol may choose to disable.  Note that
   we are using a fuzzy definition of "end user" here.  We mean not only
   the ultimate end user, but any deployer of a technology, which may be
   an entire enterprise.

So I propose that (a) developers of WS implementations MUST offer TLS support, but (b) end users of WS implementations MAY include TLS support. This means that WS implementations can be tested for full conformance, while end users have the freedom to decide whether to include or not the TLS code depending on local policy.

Alexander

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 15:37:13 -0400

The new paragraph added to 11.3.5 Sec-WebSocket-Version (page 65, line 32) contains text cut-and-pasted from Sec-WebSocket-Protocol, but missed updating the header name after the first one:

    The |Sec-WebSocket-Version| header field MAY appear multiple times in	
    an HTTP response (which is logically the same as a single |Sec-	
    WebSocket-Protocol| header field that contains all values.  However	
    the |Sec-WebSocket-Protocol| header field MUST NOT appear more than	
    once in an HTTP request.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Thursday, September 08, 2011 3:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-14.txt

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Sep 2011 17:38:02 +0100

Hi Joe,

>    the |Sec-WebSocket-Protocol| header field MUST NOT appear more than	
Thanks. Fixed in my copy.

Best Regards,
Alexey

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Sep 2011 17:43:51 +0100

>inputs could be used by a malicous peer to mount a DoS attack or exhaust
I did some tweaks to the current text based on your proposal.

---

From: Tobias Oberstein <[email-masked]>
Date: Sun, 25 Sep 2011 01:57:43 -0700

> >limitations regarding the frame size or total message size after
> >reassembly from multiple frames MUST protect against exceeding those
> limits.
> >
> >Exceeding implementation/platform specific limits on otherwise
> >unconstrained inputs could be used by a malicous peer to mount a DoS
> >attack or exhaust the peers memory.
> >"""
> >

thanks. 

I take the chance to ask whether you see any point in trying to bring the discussion about

* delivery guarantees for control frames from an endpoint POV

* ordering guarantees between control and data frames / intermediary coalescing across intermittent control frames restrictions

* latency / buffering restrictions wrt intermediaries (must they forward per-frame or may buffer msg etc)

to life again? Those are all more or less intermediary related ..

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Sep 2011 13:46:59 -0600

<hat type='AD'/>

On 9/25/11 2:57 AM, Tobias Oberstein wrote:
>>> """ Implementations which have implementation- and/or
>>> platform-specific limitations regarding the frame size or total
>>> message size after reassembly from multiple frames MUST protect
>>> against exceeding those
>> limits.
>>> 
>>> unconstrained inputs could be used by a malicous peer to mount a
>>> DoS attack or exhaust the peers memory. """
>>> 
> * ordering guarantees between control and data frames / intermediary
> coalescing across intermittent control frames restrictions
> 

Folks, we're done. Alexey and Ian are tweaking a bit of text to address
non-blocking feedback received from IESG members and WG participants,
but the time to discuss larger issues is past.

That does *not* mean we can't continue to have discussions on this list.
Indeed, I fully expect this community to work on WebSocket 1.1 a few
years from now, and it is good to gather implementation and deployment
feedback toward that effort. However, it does mean you should not expect
those discussions to result in changes to the specification at this
time, because as soon as the editors submit version -16, I am going to
approve the spec and send it to the RFC Editor team.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tobias Oberstein <[email-masked]>
Date: Sun, 25 Sep 2011 13:01:13 -0700

> Indeed, I fully expect this community to work on WebSocket 1.1 a few years
> from now, and it is good to gather implementation and deployment

ok.

since there are not a lot (any?) WS aware intermediary implementations,
it's probably the better (than mere discussion) approach anyway 

> those discussions to result in changes to the specification at this time,
> because as soon as the editors submit version -16, I am going to approve the
> spec and send it to the RFC Editor team.

ok, nice! so WS 1.0 is around the corner ..

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 25 Sep 2011 22:03:10 +0200

> approve the spec and send it to the RFC Editor team.

Hi, that's fine, but there are at least one subject for which there
has been long discussion with no conclusion at the end (the text
remains unchanged):

- WS client sends HTTP GET with "Sec-WebSocket-Protocol: bar, foo".
- WS server does not implement neither "bar" or "foo" WS subprotocols.
- What SHOULD do the server?

Discussed options:

a) (as the current text says) Nothing, just don't reply
"Sec-WebSocket-Protocol" in 101. So nobody knows what are client and
server supposed to speak now. If the server DOES know that it does not
speak the WS subprotocols offered by the client, why should it
*accept* the WS connection?

b) The server replies a *new* HTTP response, i.e. "488 WebSocket
Subprotocol Not Implemented".

IMHO b) is really better, and IMHO more people in this maillist thinks
the same, but this topic has been ignored (AFAIK).

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Sep 2011 14:08:40 -0600

> ok, nice! so WS 1.0 is around the corner ..

Perhaps it would help for me to describe what happens next.

As soon as I send out the approval notice (which I expect will happen in
the next few days), the document goes into the RFC Editor queue. Right
now the publication process is taking about 6 weeks for most documents,
although it can be slower if there are missing references, IANA
registration issues, etc. If all goes well the RFC will be published
around the time of IETF 82 in mid-November.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Sep 2011 14:53:15 -0600

> the same, but this topic has been ignored (AFAIK).

I will let the chairs discuss the particulars because I don't remember
the exact discussion, but as I recall people thought that it would be
fine for the server to accept the connection and allow the client to use
the "bare" WebSocket (despite the fact that the server does not support
those particular subprotocols).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Sep 2011 22:32:03 +0100

>That does *not* mean we can't continue to have discussions on this list.
Right.

>feedback toward that effort.
>
Well, we can start working on this now, but I would not expect to 
request publication of another RFC in a month from now ;-).
Having said that, a new RFC might take some time to get done.

>However, it does mean you should not expect

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 12:39:03 +0200

> those particular subprotocols).

So, if the negotiation fails then act as if there has been no
negotiation. Sad IMHO. A negotiation is a negotiation, not a joke that
can be forgotten if it has failed.

There is more people agreeing with me in this subject, but it seems
that the text will remain unchanged just because the discussion is
ignored.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Tue, 27 Sep 2011 08:29:57 -0400

> can be forgotten if it has failed.

A negotiation is how it is defined to be.  Think of it how airline pilots
negotiate a language to talk to the air traffic controllers.  One can say he
speaks Italian and the other French, and then they both speak English as it
is mandated to be the default if there is no agreement.  Likewise, the
default subprotocol is none if something else cannot be agreed upon.

You may not like it and have no intention of using such a default fallback,
and you are free to fail the connection in your servers if you like, but it
is still well-defined and deterministic behavior.

> that the text will remain unchanged just because the discussion is

There are also people disagreeing with you, but apparently you ignore that
part of the discussion.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 15:37:12 +0200

2011/9/27 John Tamplin <[email-masked]>:
> is mandated to be the default if there is no agreement.

That's a bad example, let me rewrite it according to what we have in
WebSocket handhsake procedure:

- Pilot wants to talk with the air controller.
- Pilot offers two languages: "Italian" and "English".
- Air controller speaks "French" and "English" so selects "English"
and announces it to the pilot.
- Both speak in Engish.

Now the other case (with my proposal):

- Pilot wants to talk with the air controller.
- Pilot offers two languages: "Italian" and "Spanish".
- Air controller speaks "French" and "English".
- Air controller rejects the talk ("I know that you can speak in
Italian and Spanish, but I speak none of them, sorry").

And again the same case (with your proposal and current draft text):

- Pilot wants to talk with the air controller.
- Pilot offers two languages: "Italian" and "Spanish".
- Air controller speaks "French" and "English".
- Air controller accepts the talk but indicates no language to the pilot.
- Pilot starts speaking in Italian, air controller starts speaking in French.
- The plain crashes and there are a lot of deaths.

> Likewise, the

I don't agree. If the client does NOT provide a list of supported
subprotocols, then I could understand the point of a "default
subprotocol". But when the client clearly says "I just speak FOO and
BAR" it makes no sense that the server (who does NOT speak FOO or BAR)
accepts the connection. IMHO it's obvious.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Tue, 27 Sep 2011 09:56:44 -0400

> and announces it to the pilot.

That is for negotiating a set of extensions.  What you are complaining about
in the WebSocket subprotocol negotiation is that the client requests a
subprotocol and the server doesn't accept it but keeps the connection up
anyway.  Ie, there is an implied default subprotocol being offered and the
server accepts that.

> Italian and Spanish, but I speak none of them, sorry").

Sure, and then the plane crashes because he can't communicate with the
controller.  That's why all international pilots are required to be
proficient in English.

> - The plain crashes and there are a lot of deaths.

No, English isn't announced -- it is the default, just like the empty
subprotocol.  So, after the pilot requests Italian or Spanish, the
controller speaks English since he doesn't speak either of those and because
the pilot is required to speak English.

It is clear you disagree with the idea of a default subprotocol, but that is
what the spec says and consensus was reached on this point long long ago.
 If you really care, then you can drop the connection if you didn't get the
subprotocol you asked for -- sure it takes an extra round trip, but since
you are killing the connection it doesn't seem important.  On the flip side,
if your suggestion were implemented, there would be no way for a client to
continue who is happy to speak the default subprotocol, and we would need a
specification defining a token for the default subprotocol, and then it
would generally be sent in every request adding untold bytes to the
cumulative WebSocket connection setup messages.  Since the common case is
going to be no subprotocol, it makes sense to make that the always-provided
default option rather than including it in every setup message.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 16:11:06 +0200

2011/9/27 John Tamplin <[email-masked]>:
> On the flip side, if your suggestion were implemented, there would be no way
> for a client to continue who is happy to speak the default subprotocol, and
> we would need a specification defining a token for the default subprotocol,
> and then it would generally be sent in every request adding untold bytes to
> the cumulative WebSocket connection setup messages.  Since the common case
> is going to be no subprotocol, it makes sense to make that the
> always-provided default option rather than including it in every setup
> message.

Hi John, I've explained several times that I'm not against the concept
of "default subprotocol" neither I want to mandate the presence of the
Sec-WebSocket-Subprotocol header in the client request.

Indeded, if the client does not present such header, the server must
understand that the default protocol is offered.

But in case the client *explicitly* says "I support FOO and BAR" and
the server does not support none of them, then it makes no sense to
start speaking.

It's different. Please understand my point. I'm not mandating the
presence of the Sec-WebSocket-Subprotocol header in client request.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Tue, 27 Sep 2011 10:23:30 -0400

> presence of the Sec-WebSocket-Subprotocol header in client request.

I understand your point.  However, if my client wants to speak the FooBar
subprotocol, but knows how to operate over the default subprotocol, it would
have to include some token for the default subprotocol in every request.

An application endpoint already defines a protocol -- I can use the existing
text and binary frames to send any data I like organized however I like.
 The only use of subprotocols is when we have something standardized that
could be offloaded to the server and understood by your favorite
intermediaries.  Until then, the subprotocol field provides no value.

When you connect to a particular WS URI, you are either talking to your own
app on the other end of the connection (or at least one speaking a public
API), so you already know how to talk to it.  If you want to support
multiple ways of communicating between them, you could put that in the WS
payload data with no loss of effectiveness.  The browser, server and
intermediaries (currently) have nothing to do with that -- all they are
doing is transferring text/binary frames for your app, regardless of
whatever the subprotocol field says.  Maybe in the future there will be some
subprotocol which can benefit from the server understanding it and
performing some functions automatically rather than leaving it up to the
app.  However, those haven't been thought of yet and certainly haven't been
vetted as to how they work on real-world WS deployments.  As such, the
subprotocol field is an extension point for future use when we figure out
what it is good for.

There are many ways the subprotocol negotiation could be implemented.  Stop
whining about the one that was chosen not being what you preferred and just
implement the spec.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 11:01:40 -0400

It seems like this is really an application layer issue.  If the negotiation fails, then the WebSocket layer tells the application, "There are no protocols that you both speak."  It's then up to the applications on either end to decide whether to proceed.  If there's some thing that it can do usefully with a generic WebSocket, then it can use it.  If not, it can terminate the connection.

--Richard

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 18:30:39 +0200

> It seems like this is really an application layer issue.  If the negotiation fails, then the WebSocket layer tells the application, "There are no protocols that you both speak."  It's then up to th…

The purpose of a WebSocket connection is to establish a session of the
negotiated (or implicit) WS subprotocol. I will never open a WS
connection just to send Ping frames.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 13:12:15 -0400

You can send frames without a subprotocol negotiated.  Applications can send whatever frames they like; they don't need to negotiate subprotocols.

--Richard

---

From: Greg Longtin <[email-masked]>
Date: Tue, 27 Sep 2011 12:12:31 -0500

Iñaki,

> I will never open a WS connection just to send Ping frames.

???

First header --

GET /* HTTP/1.1

* who I want to talk to, or *how I want to talk*.

Am I missing something?

Greg Longtin

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 19:16:52 +0200

> You can send frames without a subprotocol negotiated.  Applications can send whatever frames they like; they don't need to negotiate subprotocols.

Yes I can, but... what for?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 19:19:00 +0200

> * who I want to talk to, or *how I want to talk*.

I don't get your point. The HTTP GET for WebSocket handshake includes
"who I want to talk" (the request URI + path + query) along with "how
I want to talk" (the Sec-WebSocket-Subprotocol or the abscense of it
when I want to talk the "default" WS subprotocol).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 14:13:49 -0400

You're missing Greg's point.  If the person I'm talking to only ever speaks one thing, then I don't need to have a subprotocol with him; we already know what we're going to talk.  You could call it the "default", but it's the "default" only in the scope of this destination, not for WebSockets overall.  

That, in a nutshell, is why the subprotocol field is optional.

--Richard

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 20:16:29 +0200

2011/9/27 Richard L. Barnes <[email-masked]>:
> You're missing Greg's point.  If the person I'm talking to only ever speaks one thing, then I don't need to have a subprotocol with him; we already know what we're going to talk.

Then it makes no sense at all that the client specifies a different
subprotocol in the handshake request. The client should specify the
name of the default protocol or not specify it at all.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 27 Sep 2011 11:44:00 -0700

On 09/27/2011 11:16 AM, Iñaki Baz Castillo wrote:
> 2011/9/27 Richard L. Barnes<[email-masked]>:

"implicit subprotocol" might be clearer than "default".

If a client sends an explicit subprotocol name, it would be strange if 
the server didn't understand it.

With an implicit subprotocol (the most common case probably), both 
server and client have to agree out of band on the subprotocol details 
and format. If there are any differences, then something is wrong. If 
the client sends an explicit subprotocol name the server doesn't 
understand, it's no longer an implicit subprotocol, and almost certainly 
a problem that can be caught early.

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 27 Sep 2011 12:48:37 -0700

The difference though, is that English has defined semantics and is mostly understood and interoperates amongst speakers of that language.  The default subprotocol is completely ad-hoc, and is totally unique for every individual application.  A client's idea of what to speak as a "default" could be entirely different than the server's idea.  Sure, the client may expect the server's default because it has out-of-band, predefined knowledge of the server it is connecting to, which is the use case for not specifying a subprotocol in the handshake.  But if the client specifies subprotocols and the server doesn't understand any of them, that is clearly an unrecoverable error situation, especially if the client has knowledge of what to expect from the server - if it knows what the server can speak before initiating the connection, then it shouldn't be requesting wrong subprotocols in the first place.  There is not, nor will there ever be, a universally understood default subprotocol.  Therefore there is no comparison whatsoever to "English" as used in air traffic control.

Also, subprotocols are not analogous to server extensions at all.  A subprotocol indicates which application level protocol is expected to be spoken, such as "superchat," and is not something I would ever expect to be offloaded and handled by the websocket library layer directly.

Sent from my iPhone

On Sep 27, 2011, at 6:56 AM, John Tamplin <[email-masked]> wrote:

> No, English isn't announced -- it is the default, just like the empty subprotocol.

---

From: John Tamplin <[email-masked]>
Date: Tue, 27 Sep 2011 16:04:35 -0400

On Tue, Sep 27, 2011 at 3:48 PM, Brian McKelvey <[email-masked]>wrote:

> Also, subprotocols are not analogous to server extensions at all.  A
> subprotocol indicates which application level protocol is expected to be
> spoken, such as "superchat," and is not something I would ever expect to be
> offloaded and handled by the websocket library layer directly.
>

Imagine in the future we create a WS subprotocol for carrying VOIP traffic,
and it is negotiated.  If this is a standard subprotocol (if it isn't there
isn't much point, since you can just use no subprotocol), then you can
imagine that some of the signalling requirements might be offloaded to the
client/server rather than the app.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 22:07:27 +0200

> client/server rather than the app.

Hi John, could you please explain what you mean? I don't understand.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Bemmel, Jeroen Van (Jeroen Van)" <[email-masked]>
Date: Tue, 27 Sep 2011 22:31:10 +0200

Iñaki,

All implementations are required to support the default protocol. If a client indicates "foo, bar", and the server supports neither, the client could still decide to use the default protocol. If the server would send an error and close the connection as you are suggesting, the client would not have that choice.

The client could still decide to close the connection if it concludes that no meaningful communication is possible. The server is in no position to determine this

The client needs no error response to detect that the server does not support its suggested protocols, it can tell by the absence of the header. 

Regards,
Jeroen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: dinsdag 27 september 2011 16:11
To: John Tamplin
Cc: [email-masked]
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-14.txt

Regards.

---

From: Joe Mason <[email-masked]>
Date: Tue, 27 Sep 2011 17:15:37 -0400

One use case is when a subprotocol is developed using an ad-hoc "implicit protocol", a version is released into a the wild, and then the authors tighten up and release a spec that uses a subprotocol name.  After several revisions of the spec, we can easily imagine a client library that wants to talk to every server found in the wild using the logic:

Request "version0.1,version0.2".
If the server returns a protocol name use that version.
If the server returns no protocol name, use version0.1, assuming that this server is using the old ad-hoc spec.

I'd expect this would be pretty common.  Look at the RSS mess, for instance.  Even websockets was developed using more or less this process!

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian McKelvey
> Sent: Tuesday, September 27, 2011 3:49 PM
> To: John Tamplin
> Cc: [email-masked]
> The difference though, is that English has defined semantics and is
> mostly understood and interoperates amongst speakers of that language.
> The default subprotocol is completely ad-hoc, and is totally unique for
> every individual application.  A client's idea of what to speak as a
> "default" could be entirely different than the server's idea.  Sure,
> the client may expect the server's default because it has out-of-band,
> predefined knowledge of the server it is connecting to, which is the
> use case for not specifying a subprotocol in the handshake.  But if the
> client specifies subprotocols and the server doesn't understand any of
> them, that is clearly an unrecoverable error situation, especially if
> the client has knowledge of what to expect from the server - if it
> knows what the server can speak before initiating the connection, then
> it shouldn't be requesting wrong subprotocols in the first place.
> There is not, nor will there ever be, a universally understood default
> subprotocol
>  .  Therefore there is no comparison whatsoever to "English" as used in
> air traffic control.
> 
> subprotocol indicates which application level protocol is expected to
> be spoken, such as "superchat," and is not something I would ever
> expect to be offloaded and handled by the websocket library layer
> directly.
> 
> Sent from my iPhone
> 
> subprotocol.

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 27 Sep 2011 14:37:47 -0700

That may come to be, however that is an issue of the optimization of a server implementation, not an issue for the websocket protocol, and changes nothing about the fact that it would be an application level protocol that would be requested and that the server would have to speak in one way or another, or it would be an unrecoverable error.

Sent from my iPhone

On Sep 27, 2011, at 1:04 PM, John Tamplin <[email-masked]> wrote:

> Imagine in the future we create a WS subprotocol for carrying VOIP traffic, and it is negotiated.  If this is a standard subprotocol (if it isn't there isn't much point, since you can just use no subprotocol), then you can imagine that some of the signalling requirements might be offloaded to the client/server rather than the app.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 28 Sep 2011 09:30:48 +0900

> when I want to talk the "default" WS subprotocol).

I think for subprotocols, the call is still out on how they will 
actually be used. There are various possibilities:

1) Not at all: The server side (identified by the URI) and the client 
side (JavaScript downloaded from the server) know each other, and don't 
have to indicate or negotiate how they are going to talk to each other.

2) In great detail: Every single server endpoint (URI) will use its own 
subprotocol identifier, just to be sure there's no confusion. It may 
also be used to bundle various services at the same endpoint. The 
identifiers may also be updated carefully e.g. when some details of the 
communication at that endpoint are changed or tweaked.

3) At some intermediate level: We'll get subprotocols and corresponding 
identifiers for common application patterns (let's say something like a 
pub/sub mechanism) or application protocols (let's say something like 
chat). These identifiers will be common across many endpoints that are 
otherwise unrelated.

4) A mixture of all the above.

My guess is that Ian's (or whoever invented the subprotocol header) 
original intention was something along the lines of 3), but that we will 
mostly get 1), with potentially some places doing 2). Getting to 3), 
although in many ways desirable, may be just too difficult.

Regards,    Martin.

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 27 Sep 2011 19:02:49 -0700

That is indeed the only valid use case. I dont feel particularly strongly about this to be honest... It's not the end of the world if the client has to detect that there was no valid subprotocol supplied by the server.

Furthermore, if the server does choose to issue a 4xx response in such a case, as things stand right now, that will in fact yield the desired response of failing the connection.  I would suspect that we will see that commonly in implementations in the wild.  It is, in fact, how my server running at worlize.com functions now.

Brian

Sent from my iPhone