Re: [hybi] It's time to ship

[Ian Fette (イアンフェッティ) <[e-mail]>]

2011/1/10 Eric Rescorla <[e-mail]>

> 2011/1/10 Ian Fette (イアンフェッティ) <[e-mail]>:
> > On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau <[e-mail]> wrote:
> >>
> >> Hello Ian,
> >>
> >> On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette
> >> (????????????????????????) wrote:
> >> > >  - you're using the OPTIONS method. The WG's consensus was voted as
> >> > > using
> >> > >    GET. While technically working, OPTIONS limits some possibilities
> >> > > since
> >> > >    no path is sent to the server.
> >> > >
> >> > >
> >> > I agree it is important to be able to identify between various
> resources
> >> > on
> >> > a server. E.g. for our use, we will have multiple different websocket
> >> > endpoints, and we want our frontend to be able to dispatch to the
> >> > appropriate backend based on the information in the handshake. That
> >> > said, I
> >> > think the draft allows for that (Sec-WebSocket-URL), or as pointed out
> >> > on
> >> > another thread, it appears OPTIONS does allow for a path component.
> So,
> >> > I
> >> > think we should be able to resolve that point.
> >>
> >> Once again,I'm not opposed at all to this point. I'd even say that would
> >> it
> >> not have been accepted as a consensus in the last poll, I'd probably
> have
> >> voted for it. It's just that it's a change from what was planned till
> now
> >> and participants need to express their opinion on that point.
> >>
> >> > >  - your proposal involves AES-128-CTR. As was discussed here, it
> seems
> >> > > there
> >> > >    are still export regulations for certain countries eventhough
> >> > > they're
> >> > >    apparently fading out. It could still be a problem for companies
> >> > > who
> >> > > want
> >> > >    to export products to some countries and which never had to put
> >> > > crypto
> >> > > in
> >> > >    them.
> >> > >
> >> >
> >> > It would be nice to understand if this is actually a hard constraint.
> >> > AES-128-CTR has the benefit of being well understood, as well as fast,
> >> > as
> >> > demonstrated by Maciej in another thread. That said, I don't care
> >> > strongly
> >> > one way or another here.
> >>
> >> One of my issue with it is that despite being fast, it's a lot slower
> than
> >> simpler masking. I design software components to be used at the border
> >> side
> >> of infrastructures to dispatch the traffic to multiple servers, and I'm
> >> very much concerned by the performance limitations. On a machine which
> has
> >> normally no issue processing 10 Gbps of HTTP, I could not even process 1
> >> Gbps
> >> of WebSocket with large contents. This is much concerning because it
> >> implies
> >> that in order to build the stream analysers we've talked about in the
> >> past,
> >> it will become mandatory to install expensive crypto acceleration cards.
> >> This
> >> is not logical for a protocol which is supposed to be transferred in
> clear
> >> (ws:// as opposed to wss://). Checking for forbidden words, dangerous
> >> links
> >> or forbidden contents on campus sites will be much more expensive due to
> >> this
> >> masking algorithm alone.
> >>
> >> > >  - several people on the list asked for the ability to be able to
> >> > > disable
> >> > >    the masking in some well-controlled environments (eg:
> >> > > server-to-server
> >> > >    communications). I see no provisions for this.
> >> > >
> >> > >
> >> > There's nothing that would prevent you from writing an extension that
> >> > would
> >> > disable the masking, from my understanding.
> >>
> >> Adam did not seem favorable to that.
> >>
> >> > >  - it has not yet been stated whether only the payload or also the
> >> > > framing
> >> > >    should be masked. Your proposal masks both, which means that it
> >> > > definitely
> >> > >    blocks any possibility of performing multiplexing later. There
> does
> >> > > not
> >> > >    appear to have been a consensus in this area yet.
> >> > >
> >> > >
> >> > I'm not sure why this would block the possibility of multiplexing. I
> >> > would
> >> > agree that would be a problem if it were the case. However, a number
> of
> >> > the
> >> > early proposals for multiplexing included something like a stream-id
> in
> >> > the
> >> > frame. This could still be present. Though it would be masked, so
> would
> >> > the
> >> > length and other things that a meaningful intermediary would care
> about,
> >> > so
> >> > assuming the intermediary was capable of un-masking, is this an issue?
> >>
> >> Yes, and you got the point : if the ID is masked, how to you know which
> >> stream it is in order to pick the right unmask key ? At least the stream
> >> ID will have to be unmasked. If we prepend it before the frame, it means
> >> a new framing format. Till not it was suggested to have it in the frame.
> >>
> >
> > So, you're saying that with the XOR masking where the entire content
> > required to unmask the frame was included in the frame, it would be
> easier
> > for an intermediary to thus examine the frame? I agree that it would be
> > easier, and that in the AES method it would require an intermediary to be
> > "active" instead of "passive", e.g. terminate the connection at the
> > intermediary. I personally think that's a good argument towards XOR, but
> am
> > personally not heavily invested either way as I think for our uses, we
> would
> > be terminating at the "intermediary" anyways.
> >
>
> Ian,
>
> Im not sure Im following the reasoning here: why does the AES
> mechanism (which is,
> after all, just an XOR with a long, randomly computed mask) require an
> active intermediary?
>
> Thanks,
> -Ekr
>

I guess you're right in that it wouldn't require the intermediary to be
active. It would however require the intermediary to maintain state for each
connection, correct? (As opposed to XOR where the intermediary could be
mostly stateless as the the "masking key" would be embedded in the frame).
How large is the state that would need to be maintained?

-Ian