Re: [hybi] It's time to ship

[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