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

Re: HTTP 2.0 mandatory security vs. Amateur Radio

From: James M Snell <jasnell@gmail.com>
Date: Fri, 15 Nov 2013 11:45:51 -0800
Message-ID: <CABP7Rbdgv3MRDRV=+7DJQ5sGpWroQhMyS7Z90i0nm1CS+cWBwQ@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Nicolas Mailhot <nicolas.mailhot@laposte.net>, Bruce Perens <bruce@perens.com>, Ryan Hamilton <rch@google.com>, David Morris <dwm@xpasc.com>, HTTP Working Group <ietf-http-wg@w3.org>, Julian Reschke <julian.reschke@gmx.de>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
This quick exchange between Mike and I accidentally went offlist...
copying it here...

On Fri, Nov 15, 2013 at 11:23 AM, Mike Belshe <mike@belshe.com> wrote:
>[snip]
>
> I'm generally not in favor of this because its not deployable - we know a
> non-trivial number of home routers block ports other than 80/443.
>

Well... that's the point here, isn't it? There's a reason those
routers block other ports by default. The ability to pass HTTP/2 over
443 but not port 80 would make it easier to default secure behavior.

> So we'd be left with answering a bunch of questions in the spec about how to
> behave when switching ports all for something that couldn't be used
> reliably.  (one question - if you don't know if a server is HTTP/1 or
> HTTP/2, do you try port 80 first?  Then if you get the upgrade header, do
> you have to open a new connection?  That sounds bad, so does that mean your
> server needs to handle HTTP/2 on both 80 and 100?)
>

Nope, port 80 would be HTTP/1.x only. If you want to do plain text
HTTP/2, you'd have to use port 100. There would be no HTTP/1.x-to-2.x
upgrade path on port 80. That implies introducing a new url scheme for
plain text HTTP/2.

  http://example.org --> We're using plaintext HTTP/1.x
  http2://example.org --> We're using plaintext HTTP/2.0
  https://example.org --> We're using HTTP/1.x or HTTP/2.0

This means that if a server supports plaintext HTTP/2.0, it would need
to advertise that in a DNS SRV record and the client would explicitly
have to go look for that. If you want to allow plaintext HTTP/2
through your router, you'd have to explicitly open the port. In other
words, it makes plaintext HTTP/2 possible but more difficult than the
TLS option (which is a good thing).

- James


> Mike
>
>

On Fri, Nov 15, 2013 at 11:07 AM, James M Snell <jasnell@gmail.com> wrote:
> Perhaps a compromise approach? Allow for Non-TLS HTTP/2, but require
> it to use a new (non-80) default port. HTTP/2 over TLS would still use
> 443 by default. This would make is trivially simple to block insecure
> HTTP/2 wherever it is unwanted and easier to make secure HTTP/2 the
> default option. This doesn't solve all of the issues, but it allows us
> to move beyond the plaintext on port 80 concern (it also ought to
> greatly simplify protocol upgrade... that is, on port 80, there
> wouldn't be any protocol upgrade...)
>
> - James
>
> On Fri, Nov 15, 2013 at 9:31 AM, Roberto Peon <grmocg@gmail.com> wrote:
>> Nicolas, you're absolutely right. Deploying something that isn't part of the
>> commonly accepted subset of HTTP/1.1 over port 80 doesn't work.
>>
>> As an example, if you attempt to use a different entity-body compression,
>> for instance (something explicitly part of the HTTP/1.1 protocol), you will
>> find that the internet will have occasionally transform either the headers
>> or the entity-body or both, resulting in an uninterpretable and broken
>> resource received at the client.
>> Yes, this really happened, and oh my was it a pain to debug. In the end,
>> despite being far better for the user, this feature was disabled for port 80
>> because it was not deployable.
>>
>> And yes, you are also right that people have attempted to use other
>> protocols over port 80, and that proved problematic: The most interesting of
>> which is probably WebSockets. As mentioned previously this essentially
>> doesn't work.
>>
>> That leaves us with either using a new port (infeasible, failure rate still
>> in high 10%s) or doing something else so as to be able to deploy.
>> What is the something else would you suggest?
>>
>> -=R
>>
>>
>> On Fri, Nov 15, 2013 at 8:02 AM, Nicolas Mailhot
>> <nicolas.mailhot@laposte.net> wrote:
>>>
>>>
>>> Le Ven 15 novembre 2013 08:25, Roberto Peon a écrit :
>>> > You are saying that we should use a port other than :443 for https
>>> > traffic?
>>> > ... why?
>>> > What backdoor are we talking about?
>>>
>>> I'm saying that your whole problem with intermediaries in clear stems
>>> directly from your attempts to push a new different protocol on a port
>>> already used for something else (ie trying to enter through the back-door
>>> like a juvenile delinquent because the guard on the main entry may object,
>>> ensuring that he will consider you a suspicious character)
>>>
>>> --
>>> Nicolas Mailhot
>>>
>>
Received on Friday, 15 November 2013 19:46:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC