Re: [hybi] Proposal: HTTP upgrade process

On 8/16/10 11:05 AM, Maciej Stachowiak wrote:
> On Aug 15, 2010, at 6:23 PM, Greg Wilkins wrote:
>
>    
>> All,
>>
>> there has been a lot of posting about the -76/-00 style handshake,
>> it's HTTP compliance issues, it's fast fail (or otherwise)
>> characteristics, it security features etc.    I don't think any of the
>> conversations have been very productive nor is there any apparent
>> convergence on a solution.
>>
>> I think the reason for his is that we are starting with a solutions
>> (the 8 random bytes etc.) and trying to reverse engineer the
>> requirements for it and a retrospective consensus for it's inclusion
>> into the draft. Thus I would like to propose  that we re-start
>> consideration of the handshake with the -75 style handshake and try to
>> move forward from there by identifying problems/requirements,
>> discussing solutions and then applying the consensus solution to move
>> forward.
>>      
> It's not clear to me if the random 8 bytes have been sufficiently justified. My understanding is that it's intended as a fast-fail mechanism for problematic intermediaries, but I don't think it's been demonstrated that it works. However, I do not think reverting to an earlier version of the protocol would be a productive step:
>
> (1) The WG adopted the -76 version. It seems reasonable to me that we should move forward from there. Jumping back to earlier versions will just force us to re-solve various problems.
>    
as explained in previous mail

    draft-ietf-hybi-thewebsocketprotocol-00 was used as an input document
    for the HyBi WG.  As it is an Internet-Draft, it is work in
    progress.  In other words, it is subject to change.

having said that, I agree that any changes should move the spec forward, 
be an improvement and solve the issues that
have been founded and largely discussed within the WG.
So restart from -75 does not make sense.

> (2) The -75 version had significant vulnerability to cross-protocol attacks, which is a critical security issue. While -76 is not the best effort we've seen, it is far better than -75. These security fixes are not all dependent on the magic 8 bytes. I think it would be irrational to revert critical security security fixes over a tangentially related issue.
>
> (3) At the time of the -75 draft, it was claimed by many WG that it was not HTTP compliant. If that is indeed the case, then I do not see what purpose is served by trading the non-HTTP-compliance of -76 for the different non-HTTP-compliance of -75.
>
> Conclusion: we should solve the "8 random bytes" problem, or at least, figure out if the benefits outweigh the costs, but not by reverting to an earlier draft.
>    
there has been a lot of mails and good technical discussion about
- the need of "8 random bytes" for security reasons
- the fact that as the "8 random bytes" are used  in the 00 wg version 
they do not work for reverse proxies and are non-HTTP-compliance,
- the possibility to use the "8 random bytes" in a way that both work 
with reverse proxies and are HTTP-compliance among the others:

    * inserting the 8 random bytes in an header
    * using the Willy Tarreau analysis/proposal explained in
      http://www.ietf.org/mail-archive/web/hybi/current/msg03238.html

So in order to move the work forward I would invite people to send out 
text (in an adhoc thread) proposing an handshake that address all the 
concerns raised from
different people (in the same way is happening for the frame issue).

regards
/Sal

> Regards,
> Maciej
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>    

-- 
Salvatore Loreto
www.sloreto.com