W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [hybi] workability (or otherwise) of HTTP upgrade

From: John Tamplin <jat@google.com>
Date: Tue, 07 Dec 2010 09:31:26 +0000
Message-ID: <AANLkTi=QdjzG9sN2QH-kAqVNvDnPpWDTKrOMxC1wt_sT@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
Cc: Maciej Stachowiak <mjs@apple.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Dec 7, 2010 at 2:31 AM, Greg Wilkins <gregw@webtide.com> wrote:
> I do come back to the fact that using another port does not give a
> perfect success rate, but then neither does CONNECT or
> GET+Upgrade+Hello.    Opening new ports seams like an easier ask than
> convincing intermediaries to change their CONNECT and/or Upgrade
> handling.

I asked if we should consider that option in
http://www.ietf.org/mail-archive/web/hybi/current/msg04563.html and
there seemed to be little support for it and would require changing
the charter of the group.

Options at this point:
 1) stick with GET+Upgrade, which probably means masking
     everything in the payload in a way which can't be attacker
     controlled, which seems expensive
 2) convince detractors that using CONNECT as proposed is
     not violating the HTTP spec
 3) use a dedicated port, which means changing the charter
     and still requires addressing cross-protocol attacks in
     attacker-controlled payload
 4) wait for TLS-NPN or just use GET+Upgrade always over
     TLS on port 44 (ws vs wss would indicate whether to
     validate the cert)
 5) something else that hasn't had much discussion, such as
     POST chunked encoding in each direction

Any other options?

-- 
John A. Tamplin
Software Engineer (GWT), Google
Received on Tuesday, 7 December 2010 10:44:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT