Re: [hybi] Handshake was: The WebSocket protocol issues.

[James Graham <[e-mail]>]

On 10/11/2010 02:28 PM, Greg Wilkins wrote:
>
>
> On 11 October 2010 20:34, Maciej Stachowiak <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On Oct 11, 2010, at 2:24 AM, James Graham wrote:
>      > I'm not sure I follow this objection. Unless I am
>     misunderstanding Adam's proposal, all the information needed to
>     access the Host header is in the initial client request; the only
>     additional effort needed is to use the client-sent key to decrypt
>     the headers. According to this understanding, one doesn't have to
>     maintain state across requests just to determine if one will handle
>     the request and, if so, with which back end server.
>
>     I agree with this understanding. With Adam's elaborations (not fully
>     detailed in the original proposal), all the routing information is
>     available in the initial client handshake request.
>
>      > Is it just the decryption that you believe represents an
>     unmanagable burden?
>
>     In the unlikely case that the encryption is an unreasonable burden,
>     I think it's possible to use a trivial form of encryption (XOR with
>     one-time pad) instead of AES-128-CTR. But I think it's probably both
>     safer and typically easier to use a well-known cipher.
>
>
>
> I think there are things that we can do to restrict "attacker" content
> in the handshake short of encryption.

So there is an underlying issue here that I don't understand. It seems 
clear to me that Adam and Eric's proposed handshake has a better 
security story with regard to cross-protocol attacks than -75, -76, or 
any other proposal other than using NPN with TLS. However there seem to 
be a number of people who have problems with this proposed handshake to 
the extent that they are prepared to forgo the security properties in 
order to get something different. In general people seem to be aware 
that they are making the security weaker since the arguments are mostly 
about how different approaches will probably be good enough in practice 
even though they are theoretically inferior.

What I haven't followed is what the problems with the proposal actually 
are. I understand that I have likely missed these in other messages, but 
it would be helpful if people who believe that the proposed approach, or 
aspects of it, are unworkable could summarise the outstanding issues 
they see.