Subject: [hybi] Do we need to change the framing again?

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Jan 2011 18:15:16 +0000

Much of the design of the framing was in support of being able to  
perform lightweight streaming and sendfile() operations. Many of us  
went along with various very vocal requests for this, leading to a  
63-bit frame size, for example, which is impractical with masking. We  
all, I think, universally assumed a symmetric framing, whereas we  
have now discarded the symmetry anyway.

Given that we now require making, and (as EKR points out in another  
mail), this in turn requires that the per-frame key is transmitted at  
the end of each block, which damages streaming, should we be  
revisisting these early design decisions?

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: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 10 Jan 2011 10:18:35 -0800

Please god no. We're just now at the point of hopefully getting agreement on
the handshake and being able to ship something, let us not re-open the whole
framing debate or it will be 2012 before we ship anything.

-Ian

On Mon, Jan 10, 2011 at 10:15 AM, Dave Cridland <[email-masked]> wrote:

> Much of the design of the framing was in support of being able to perform
> lightweight streaming and sendfile() operations. Many of us went along with
> various very vocal requests for this, leading to a 63-bit frame size, for
> example, which is impractical with masking. We all, I think, universally
> assumed a symmetric framing, whereas we have now discarded the symmetry
> anyway.
>
> Given that we now require making, and (as EKR points out in another mail),
> this in turn requires that the per-frame key is transmitted at the end of
> each block, which damages streaming, should we be revisisting these early
> design decisions?
>
> Dave.
> --
> Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]<[email-masked]>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Jan 2011 19:37:38 +0000

On Mon Jan 10 18:18:35 2011, Ian Fette (イアンフェッティ)  
> framing debate or it will be 2012 before we ship anything.

Well, indeed, but given EKR's recent message, I feel it's rather too  
late to do anything but, unfortunately. EKR's already suggesting a  
length|payload|key framing, after all, and there's little point in  
having the length twice.

But note that during the masking debate, any requirements which ran  
contrary to masking were discarded, so many of the requirements we  
based this framing design on are no longer in force anyway.

Dave.

---

From: John Tamplin <[email-masked]>
Date: Mon, 10 Jan 2011 14:46:00 -0500

> assumed a symmetric framing, whereas we have now discarded the symmetry

Why is a 63-bit frame size impractical with masking?  As long as the
masking key is before the payload that is masked, you can apply it as
you go with minimal cost.  The server->client connection isn't masked,
and the proponents of sendfile() compatibility were talking about the
server, so that hasn't changed either.

> each block, which damages streaming, should we be revisisting these early

I do not believe it is necessary or desirable to place the key at the
end of the frame.  What is required is that the client can't alter the
payload of a frame while it is in progress.  For a streaming
application, I would expect the typical application to have a buffer
and to write a fragment when the buffer is full or the message is
terminated - which doesn't allow the client to alter the message after
the server might have received the key.  The one case which might be a
problem in the future, is when JS supports a byte buffer API -- the
browser would just have to make sure that the JS code can't modify the
byte buffer while the message is being written to the network.

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

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 10 Jan 2011 12:18:28 -0800

On Mon, Jan 10, 2011 at 11:46 AM, John Tamplin <[email-masked]> wrote:

> mail),
I would personally agree that I don't want to see the key at the end. It
makes it impossible to do anything useful with it until we have all the
data, which seems tragic.

-Ian

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 21:53:57 +0100

> data, which seems tragic.

I'm neutral on the key before / key after issue (as I'm not a fan of
streaming and would have been happy with a 16 bit length).

But it is good to see that an advocate of strong masking are prepared
to accept unmasked framing in the form of

   length
   data
   key

as that is only a few short step to

  opcode
  length
  key
  data

and then we can keep our framing as is.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Jan 2011 21:07:01 +0000

> and then we can keep our framing as is.

Well, you can't have the length at the front of the frame, obviously.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Jan 2011 21:14:05 +0000

> Well, you can't have the length at the front of the frame,  

Well, maybe not so obvious - a length of between 5135603447290989056  
and 5135603447290989311 inclusive encodes as a string of 'GET / \r\n'  
followed by a junk octet. As a 63-bit length, this would be valid if  
we assume a 64-bit length field.

Same problem - an attacker controls the bits on the wire, only this  
time they're controlling the ideal bits on the wire to mount their  
attack.

I don't think, for a moment, that an attacker within a browser's  
sandbox is likely to be able to coerce WebSocket into sending such a  
frame, given it's pushing 4.5 petabytes, but I suppose a browser  
might have some length overflow/underflow case that's exploitable in  
this way.

Dave.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 10 Jan 2011 13:26:37 -0800

Having the mask-key at the end makes it hard to do the right thing quickly
(low latency), or efficiently (low memory) for medium to large sized
messages assuming no fragmentation.
I do prefer having the frame include the key (e.g. as Greg proposes) in the
initial framing data.

I don't believe that the length bits are an interesting attack vector as the
browser would need something that size before it could encode that length.
Or are we assuming that the browser will send the header before it has all
of the data for the message? That'd be bizzare.
-=R

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Jan 2011 21:38:25 +0000

> of the data for the message? That'd be bizzare.

Well, I don't believe that the attacks mitigated by the masking are  
an interesting attack vector, but we're still protecting against it.

If such a vulnerability in the length encoding were exploited, I'd  
expect it to be exploited by a bug in the length calculation of the  
browser's framing implementation, and not by actually trying to send  
that much data. But given the working group's attitude to protecting  
against theoretical bugs in the intermediaries and servers, I figured  
I ought to raise this possibility at least.

Dave.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 10 Jan 2011 13:40:00 -0800

Okdokie, thanks for the explanation!
-=R

On Mon, Jan 10, 2011 at 1:38 PM, Dave Cridland <[email-masked]> wrote:

> Well, I don't believe that the attacks mitigated by the masking are an
> interesting attack vector, but we're still protecting against it.
>
> If such a vulnerability in the length encoding were exploited, I'd expect
> it to be exploited by a bug in the length calculation of the browser's
> framing implementation, and not by actually trying to send that much data.
> But given the working group's attitude to protecting against theoretical
> bugs in the intermediaries and servers, I figured I ought to raise this
> possibility at least.
>
>
> Dave.
> --

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 11 Jan 2011 00:04:30 +0100

> data, which seems tragic.

indeed, and it would also make it impossible to send large frames. Right
now we support lengths up to 63 bit, but anything more than a few tens
of kB is going to be painful on some components, especially those which
are designed to support vast amounts of concurrent connections.

Willy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 11 Jan 2011 09:58:07 +0900

> of the data for the message? That'd be bizzare.

That's not only bizzare, it would also be a security risk, in that the 
server and the client could exchange data about the masking key(stream) 
in a side channel, allowing the client to create data that it knows what 
it will look after masking. This is a security concern that we have to 
warn against in the security section.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 14 Jan 2011 05:42:20 +0000

> are designed to support vast amounts of concurrent connections.

I agree - you have to use small frames when there's any kind of concurrency.

Intermediaries needn't be bothered by larger frames, as long as they
can split them into pieces during forwarding if they might modify the
stream (even if it's just to insert a control message).

Of course they can only do that if the key isn't at the end...

Btw, it's quite feasible that some 1Tb/s networks in the next 10 years
will have megabyte-sized packets, running over IPv6.

-- Jamie