Re: [hybi] Proposal: HTTP upgrade process

[Maciej Stachowiak <[e-mail]>]

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.

(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.

Regards,
Maciej