Subject: HTTP 2.0 mandatory security vs. Amateur Radio

From: Bruce Perens <[email-masked]>
Date: Wed, 13 Nov 2013 21:07:15 -0800

Amateur radio, commonly referred to as "ham radio", is prohibited
from using encryption to obscure the message content by both
international law (an ITU treaty) and its implementations in the
national law of most nations. However, we can use encryption that doesn't
obscure message content for the purposes of authentication. Use of
an https URL over an Amateur Radio connection would be a rule
violation.

Although I am well able to discuss the rationale for the prohibition
of encryption, that's probably off-topic for this list. Please take
it as a given that it's necessary and we like it this way. Anyone
who wishes to know more can email me directly.

Radio Amateurs use wifi-like networks, using 802.11 equipment on its
usual frequencies or transverting it to other frequencies, and
sometimes with a lot more power than non-licensed users are allowed.

Although our routers often run OpenWRT or something similar so that
we can add ham-specific protcols, we  use off-the-shelf computing
equipment, operating systems, and web browsers.

It would cause us some significant pain if web browsers stopped
enabling unencrypted http connections. We'd have to proxy https to
http before we allowed the signal on to Amateur frequencies, in
order to remain in legal compliance.

I doubt we're the only people in the world who must, or would
rather, have their communications in the clear.

Thanks

Bruce Perens K6BP

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 21:13:50 -0800

Can you just use unencrypted HTTP/1.X?

On Wed, Nov 13, 2013 at 9:07 PM, Bruce Perens <[email-masked]> wrote:

>  Amateur radio, commonly referred to as "ham radio", is prohibited from
> using encryption to obscure the message content by both international law
> (an ITU treaty) and its implementations in the national law of most
> nations. However, we can use encryption that *doesn't* obscure message
> content for the purposes of authentication. Use of an https URL over an
> Amateur Radio connection would be a rule violation.
>
> Although I am well able to discuss the rationale for the prohibition of
> encryption, that's probably off-topic for this list. Please take it as a
> given that it's necessary and we like it this way. Anyone who wishes to
> know more can email me directly.
>
> Radio Amateurs use wifi-like networks, using 802.11 equipment on its usual
> frequencies or transverting it to other frequencies, and sometimes with a
> lot more power than non-licensed users are allowed.
>
> Although our routers often run OpenWRT or something similar so that we can
> add ham-specific protcols, we  use off-the-shelf computing equipment,
> operating systems, and web browsers.
>
> It would cause us some significant pain if web browsers stopped enabling
> unencrypted http connections. We'd have to proxy https to http before we
> allowed the signal on to Amateur frequencies, in order to remain in legal
> compliance.
>
> I doubt we're the only people in the world who must, or would rather, have
> their communications in the clear.
>
>     Thanks
>
>     Bruce Perens K6BP
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 13:26:38 +0800

Just to make sure it’s understood — we’re talking about the common Web browsing use case (most people’s experience of the “open Web”), not other uses of HTTP. Are you saying that people put a network using amateur radio between a browser and “normal” Web sites, thereby disallowing use of https:// URLs?

If so, what do amateur radio operators in this situation do for https:// URIs today?

Regards,

On 14 Nov 2013, at 1:07 pm, Bruce Perens <[email-masked]> wrote:

> Amateur radio, commonly referred to as "ham radio", is prohibited from using encryption to obscure the message content by both international law (an ITU treaty) and its implementations in the national law of most nations. However, we can use encryption thatdoesn't obscure message content for the purposes of authentication. Use of an https URL over an Amateur Radio connection would be a rule violation.
> 
> Although I am well able to discuss the rationale for the prohibition of encryption, that's probably off-topic for this list. Please take it as a given that it's necessary and we like it this way. Anyone who wishes to know more can email me directly.
> 
> Radio Amateurs use wifi-like networks, using 802.11 equipment on its usual frequencies or transverting it to other frequencies, and sometimes with a lot more power than non-licensed users are allowed.
> 
> Although our routers often run OpenWRT or something similar so that we can add ham-specific protcols, we  use off-the-shelf computing equipment, operating systems, and web browsers.
> 
> It would cause us some significant pain if web browsers stopped enabling unencrypted http connections. We'd have to proxy https to http before we allowed the signal on to Amateur frequencies, in order to remain in legal compliance.
> 
> I doubt we're the only people in the world who must, or would rather, have their communications in the clear.
> 
>     Thanks
> 
>     Bruce Perens K6BP

--
Mark Nottingham   http://www.mnot.net/

---

From: Bruce Perens <[email-masked]>
Date: Wed, 13 Nov 2013 21:32:05 -0800

On 11/13/2013 09:13 PM, William Chan
(陈智昌) wrote:

For a time. But old protocols tend to be desupported as new versions
evolve, especially in a security-conscious environment.

I also having trouble believing that all users are content to have a
secure environment enforced upon them 100% of the time by protocol
designers. For example, for the past decade I have destroyed
encrypted emails unread, because I dislike being involved in topics
that would require them. I'd hate to be constrained to use them.

Certainly there is more we can do to protect the naive user. But
perhaps it belongs elsewhere.

---

From: Bruce Perens <[email-masked]>
Date: Wed, 13 Nov 2013 21:43:31 -0800

On 11/13/2013 09:26 PM, Mark Nottingham
wrote:

We should be preventing access to https URLs from the radio side,
and should be preventing access to the radio side by unlicensed
persons on the global Internet. We have IPV4 address block 44/8 on
the global internet (see http://en.wikipedia.org/wiki/AMPRNet),
so some radio networks would be routable from the global internet
without firewall rules.

Consider that today we could deploy a commercial web server and a
commercial web browser on the radio network, and they will operate
in a rule-compliant manner as long as we use http. It would be a
shame if those commercial products stopped working for us.

Thanks

Bruce

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 13:58:26 +0800

On 14 Nov 2013, at 1:43 pm, Bruce Perens <[email-masked]> wrote:

> Consider that today we could deploy a commercial web server and a commercial web browser on the radio network, and they will operate in a rule-compliant manner as long as we use http. It would be a shame if those commercial products stopped working for us.

Fair enough. 

The Web server can still deploy HTTP/1 over http:// URIs, and browsers (commercial or not) should be supporting that for a long, long time.

There’s some notion that browsers might support HTTP/2 for http:// URIs when it’s *not* the “general/open” Internet; it sounds like your use case might fall into this bucket.

Cheers,

---

From: Bruce Perens <[email-masked]>
Date: Wed, 13 Nov 2013 22:14:25 -0800

On 11/13/2013 09:58 PM, Mark Nottingham
wrote:

I'd be more comfortable with MUST than might. Making http an
optional feature will guarantee that we are forced off of the
mainstream once version 1.1 dies, in perhaps 10 years, and will have
to use either open source or specially-crafted proprietary software
at that time. Much as I love Open Source, I'm not sure we should be
in the position of forcing people to use it.

Thanks

Bruce

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 00:16:02 -0800

One of the reasons why http/1.1 is what people use on port 80 is because
that is all which reliably traverses it.

Deployment of http2.0 on port 80, unencrypted, across the internet would be
a reliability and support nightmare. The spec could attempt to mandate it,
but I don't see that actually changing anything about how they would be
forced to deploy it over the internet. That would be a poor idea.

-=R
On Nov 13, 2013 8:17 PM, "Bruce Perens" <[email-masked]> wrote:

>  On 11/13/2013 09:58 PM, Mark Nottingham wrote:
>
>
>
>
>  I'd be more comfortable with MUST than might. Making http an optional
> feature will guarantee that we are forced off of the mainstream once
> version 1.1 dies, in perhaps 10 years, and will have to use either open
> source or specially-crafted proprietary software at that time. Much as I
> love Open Source, I'm not sure we should be in the position of forcing
> people to use it.
>
>     Thanks
>
>     Bruce
>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 10:09:50 +0100

> that is all which reliably traverses it.

And it reliably traverses it because there is a wide array of solutions on
the market that permit its filtering. If you remove this security
property, port 80 reliable availability will become something of the past
and it will join the long list of protocols too annoying to control to be
permitted on network boundaries.

Most people do not trust random server hosts on the Internet. Mandatory
TLS assume they will. Given how diverse the human population is, there is
no chance in hell for that to happen. (yes this wg can remove possibility
of fine-grained filtering. You'll see people dropping whole continents at
the ip level instead, like already happens for mail).

There have still not been any explanation why traffic must be 100%
encrypted. People do not wear black balaclavas by default in real life
just in case a CCTV camera or a Google car passes by.

-- 
Nicolas Mailhot

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 01:19:00 -0800

> permitted on network boundaries.

No, you have this backwards.
ONLY HTTP1.1 TRAVERSES PORT 80 RELIABLY.
ONLY HTTP/1.1!

NOTHING ELSE.

> just in case a CCTV camera or a Google car passes by.

Are you not current with the news about pervasive monitoring?

-=R

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Nov 2013 09:56:04 +0000

Hi Bruce,

On 11/14/2013 05:07 AM, Bruce Perens wrote:
> Amateur radio, commonly referred to as "ham radio", is prohibited from using 
> encryption to obscure the message content by both international law (an ITU 
> treaty) and its implementations in the national law of most nations. However, we 
> can use encryption that /doesn't/ obscure message content for the purposes of 
> authentication. Use of an https URL over an Amateur Radio connection would be a 
> rule violation.
> 
> encryption, that's probably off-topic for this list. Please take it as a given 
> that it's necessary and we like it this way. Anyone who wishes to know more can 
> email me directly.

Well, I don't think its that simple to be honest. If there are
good reasons to prefer the status quo that's fine, but that
treaty is a fairly old thing and I think the argument that we
should hold up security improvements in the web on that basis
is not at all compelling. One could equally argue that today's
common use of crypto for communication on the Internet and the
web indicates that that treaty is now past its sell-by date.
(I do realise that's not a usefully actionable argument for
ham radio users.)

Occasionally we're told that there are places in the world
where current crypto is illegal (usually without reference to
specific laws), but we nonetheless use strong crytpo in our
protocols, going all the way back to RFC 1984. And we're right
to do that. So your argument would also apply to an IPsec VPN
but yet I don't see an argument that such VPNs ought only
use AH and not ESP.

> frequencies or transverting it to other frequencies, and sometimes with a lot 
> more power than non-licensed users are allowed.

There could be an interesting workshop paper on how HTTP/2.0
would run over AX.25 for sure. Has anyone done that? I'd
wonder if there are other non-security features of HTTP/2.0
(as currently proposed) that would make it more or less
well suited for use in such networks.

> Although our routers often run OpenWRT or something similar so that we can add 
> ham-specific protcols, we  use off-the-shelf computing equipment, operating 
> systems, and web browsers.
> 
> unencrypted http connections. We'd have to proxy https to http before we allowed 
> the signal on to Amateur frequencies, in order to remain in legal compliance.

Yes, that's true. The same is true for people who do DTN experiments
(like me) where we have tried out various ways to get HTTP traffic
to very odd places using RFC 5050. Now while ham radio is a much
more real use-case than DTN, personally I think that the good for
the billions of users of the web should outweigh the needs of such
tiny communities in general.

Cheers,
S.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 11:13:52 +0100

> Are you not current with the news about pervasive monitoring?

Are you not current with the way CCTV cameras have mushroomed everywhere,
Google cars capture passer-bys and *people* *don't* *care* (and when they
care the solution is legislation like European privacy laws, not technical
constrains. Please fix your laws if you don't like them don't foster
technical limits on everyone else).

-- 
Nicolas Mailhot

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 09:05:15 -0800

While the treaty is old, the latest FCC review of the issue concluded just a month ago, An encryption ban is there for the foreseeable future and we like it that way, the rest of that discussion belongs off-list.

The presence of Amateur Radio makes an important point here, though: the global internet is far from the only user of the HTTP protocol. Comcast is another good example, they operate a huge private IPV6-only net over which there is lower-layer security and the high-layer band-aid of TLS is not necessary. Conventional internet traffic is encapsulated before being carried on the Comcast network, and is a minority payload there. But HTTP is an oft-used tool within the Comcast network.

The creation of a Concealment Society carries its own evils, rather than being a completely benign and freedom-preserving response to the problem of government and corporate surveilance. Not everyone opposes such surveilance, and not everyone is in favor of private efforts to defeat it. An HTTP protocol which provides us with no means of opting out of the Concealment Society takes out of our hands a choice that should be ours.

     Thanks

     Bruce

Stephen Farrell <[email-masked]> wrote:
>If there are good reasons to prefer the status quo that's fine, but that treaty is a fairly old thing
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 09:49:54 -0800

There is a means of opting out, however, which exists and is widely
deployed: http1

There was near unanimity at the plenary that we should do something about
pervasive monitoring, and while I don't believe that there were any
actuonable , unambiguous dieectuves , the spirit of the room was quite
clear. The IETF intends to attempt to do something about this.

Even were that not the case, websites are changing to https for various
other reasons, and under Mark's proposed option C, http2 would be for those
URLs while http1 would be used for URLs with an http scheme.

Your larger problem is not that http2 will do encryption, but rather that
sites are choosing to use https. No protocol change or spec change can
protect the HAM community from that sea-change.

-=R
 On Nov 14, 2013 7:06 AM, "Bruce Perens" <[email-masked]> wrote:

> While the treaty is old, the latest FCC review of the issue concluded just
> a month ago, An encryption ban is there for the foreseeable future and we
> like it that way, the rest of that discussion belongs off-list.
>
> The presence of Amateur Radio makes an important point here, though: the
> global internet is far from the only user of the HTTP protocol. Comcast is
> another good example, they operate a huge private IPV6-only net over which
> there is lower-layer security and the high-layer band-aid of TLS is not
> necessary. Conventional internet traffic is encapsulated before being
> carried on the Comcast network, and is a minority payload there. But HTTP
> is an oft-used tool within the Comcast network.
>
> The creation of a Concealment Society carries its own evils, rather than
> being a completely benign and freedom-preserving response to the problem of
> government and corporate surveilance. Not everyone opposes such
> surveilance, and not everyone is in favor of private efforts to defeat it.
> An HTTP protocol which provides us with no means of opting out of the
> Concealment Society takes out of our hands a choice that should be ours.
>
>      Thanks
>
>      Bruce
>

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 10:23:02 -0800

On 11/14/2013 09:49 AM, Roberto Peon
wrote:

There is a means of opting out, however, which exists
and is widely deployed: http1

This isn't realistic unless the HTTP 2 specification makes
support of HTTP 1 mandatory. Which of course is silly.

There was near unanimity at the plenary that we
should do something about pervasive monitoring

You had a humming vote to give yourselves the new
mission of curing social and political ills rather than technical
ones, by inflicting a mandatory encryption requirement on
everyone, everywhere? It sounds like a big over step.

Let's make this more clear and ignore the Amateur Radio
issue for now. I don't wish to be forced into concealment in my normal
operations on the Internet.

Nor do I wish to have traffic over my personal network
which I can not supervise. Unfortunately, there are a lot of
operating systems and applications that I have not written which
use that network. When I can't see the contents of their network
traffic, it is more likely that traffic is being used to eavesdrop
upon me. Surrounding that traffic with chaff by requiring
encryption of _all_ HTTP traffic means that this hostile
encrypted traffic will be impossible to find.

Thus, my security is reduced.

Even were that not the case, websites are changing to
https for various other reasons

That's fine, because it's their choice or the users choice. Not
yours.

Thanks

Bruce

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Nov 2013 19:40:46 +0100

> There is a means of opting out, however, which exists and is widely

And the WG has a mandate to develop a replacement for 1.1, called 2.0. 
If we do not indent to develop that protocol anymore, we should re-charter.

> There was near unanimity at the plenary that we should do something
> about pervasive monitoring, and while I don't believe that there were
> any actuonable , unambiguous dieectuves , the spirit of the room was
> quite clear. The IETF intends to attempt to do something about this.

Yes. What we disagree on what that means for HTTP: URIs.

> ...

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 10:49:37 -0800

On Thu, Nov 14, 2013 at 10:40 AM, Julian Reschke <[email-masked]> wrote:
> And the WG has a mandate to develop a replacement for 1.1, called 2.0. If we
> do not indent to develop that protocol anymore, we should re-charter.
>

Very emphatic +1. So far the general sentiment of those pushing for
TLS-only seems to be "If you don't want to be forced to use TLS,
tough, you don't get to play with us then". That's not going to work.

- James

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 21:05:18 +0100

> protect the HAM community from that sea-change.

That would be more convincing without the frantic attempts to make tls
mandatory instead of relying on web site choices…

-- 
Nicolas Mailhot

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:19:48 -0800

You're mischaracterizing.

The Http/2 spec includes mechanisms for using it without encryption.

Encryption, however, is mandatory for web deployment across the internet in
reality because of the difficulty in achieving reliable communications.
That is just the way it is. Not my fault. :)

-=R
On Nov 14, 2013 10:05 AM, "Nicolas Mailhot" <[email-masked]>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:21:55 -0800

It is a fact of deployment, however.
We can wish honey dreams all day and night long of a web where deploying
plaintext works (yes, ignoring the pervasive multi-party surveillance), but
it does little to change reality where it does NOT work reliably.

-=R
On Nov 14, 2013 8:49 AM, "James M Snell" <[email-masked]> wrote:

> If we

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:25:22 -0800

As I seem to be saying over and over...

We can wish for plaintext http2 over the internet on port 80 as much as we
want, but it won't happen since it is not reliable, and the nature of that
unreliability is not predictable.

Few websites will be willing to turn on http2 if it means losing 10-20% of
their user base. And that really is what we are talking about.

-=R
On Nov 14, 2013 8:40 AM, "Julian Reschke" <[email-masked]> wrote:

> And the WG has a mandate to develop a replacement for 1.1, called 2.0. If
> we do not indent to develop that protocol anymore, we should re-charter.
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Nov 2013 21:33:42 +0100

On 2013-11-14 21:25, Roberto Peon wrote:
> We can wish for plaintext http2 over the internet on port 80 as much as
> we want, but it won't happen since it is not reliable, and the nature of
> that unreliability is not predictable.
>
> Few websites will be willing to turn on http2 if it means losing 10-20%
> of their user base. And that really is what we are talking about.
>
> -=R

It may very well be true that the best we can come up with isn't 
deployable on the public internet where you need to deal with broken 
intermediaries. But that's different from giving up right now.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 12:35:11 -0800

As far as I can tell, none of us who are saying no to mandatory TLS
aren't wishing "for plaintext http2 over the internet on port 80". By
all means, make HTTP2 over TLS the default setup. What we are saying
is that making HTTP2 over TLS *mandatory* is not the right thing to
do.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:39:22 -0800

There is a separate argument for authenticated vs non-authenticated TLS
that from a security perspective.

-=R
On Nov 14, 2013 10:35 AM, "James M Snell" <[email-masked]> wrote:

> we
> of
> If

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 21:46:17 +0100

> their user base. And that really is what we are talking about.

You can be reliable from a technical point of view, that won't stop you
from being deliberately blocked if you try to bypass everyone else, and
once you're blocked we'll talk again about user base loss

You can't have it both ways, play alone and claim ubiquity.

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 21:47:11 +0100

Hi Julian,

> intermediaries. But that's different from giving up right now.

Which is exactly why I think that making it the default for HTTPS *and*
allowing it for HTTP but not by default is a reasonable approach. It
will allow users to taste the new speed of HTTP/2. And when they're on
an HTTP/1.1 site, they'll have two options to use it in 2.0 : contact
the web site owner to ask him to move to TLS and try by themselves to
enable HTTP/2 in their browser (for browsers that will accept it).

It has worked for the transition between 1.0 and 1.1, we ended up
quickly with 1.1 being used by default. Then same for keep-alive
which was broken for a long time. Then keep-alive to proxies, then
1.0 vs 1.1 to proxies. Even pipelining which was not generalized by
default in all browsers due to the difficulty of getting it right.
It also worked for SSLv2 to SSLv3 which were incompatible on the
wire.

I don't see why it wouldn't work with HTTP/2 as well if there is
incentive for end users to try to get a better experience. But we
can expect that 2.0 over TLS will work at more places than 2.0 in
clear.

Note that this might possibly change quickly due to the massive
incentive that TLS-everywhere creates for MITM proxies which will
have even more trouble letting HTTP/2 pass through without a code
upgrade... TLS was the preferred transport in part because it was
less affected by MITM boxes, and now it's changing because we try
to do things in the wrong order.

I just hope we won't reach the point where port 80 is more reliable
than port 443, because it will mean we'd have significantly degraded
the Net.

Best regards,
Willy

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 12:51:50 -0800

On 11/14/2013 12:21 PM, Roberto Peon
wrote:

We can wish honey dreams all day and night long of a web where
deploying plaintext works

Gosh, how badly that dumb Tim B-L failed because he didn't encrypt
from the very start. The web might have been a success if he'd just
listened to you. :-)

Plaintext works if you aren't attempting to subvert the entire
protocol by tunneling through it.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 14 Nov 2013 15:51:49 -0500

All,

A proposal:

1. Include a discussion of proxy issues inherent in running HTTP/2.0 over plaintext: unreliable, undiscoverable, etc.

2. Include a discussion of common TLS issues - mostly pointers to the appropriate RFCs - that honestly talks about the concerns that have been expressed on this list.

3. Require client and server to support both http:// (with upgrade) and https:// (with ALPN)

4. Place a requirement on public-facing HTTP/2.0 servers: MUST NOT advertise HTTP/2.0 support in response headers, MUST NOT support HTTP/2.0 upgrade. This defines a concrete way to actually “enforce” the use of HTTP/2.0 w/TLS *or* HTTP/1.1 w/o TLS (depending on the client/network capabilities) instead of hand waving and putting the onus on clients to guess whether a connection is local or over the public web.

5. Define/reference a mechanism that allows a HTTP server to advertise that it supports access via https:// - there is at least one draft for this, but this allows a client/user agent to opportunistically use https:// over http://. (For the general case this may not be needed - try connecting on port 443 first, or in parallel with port 80…)

Thoughts?

On Nov 14, 2013, at 3:25 PM, Roberto Peon <[email-masked]> wrote:

> We can wish for plaintext http2 over the internet on port 80 as much as we want, but it won't happen since it is not reliable, and the nature of that unreliability is not predictable.
> 
> Few websites will be willing to turn on http2 if it means losing 10-20% of their user base. And that really is what we are talking about.
> 
> -=R
> 
> And the WG has a mandate to develop a replacement for 1.1, called 2.0. If we do not indent to develop that protocol anymore, we should re-charter.
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 13:14:25 -0800

Ha! Nice turn of phrase there.

I don't see how anyone developing http could have expected what has
developed.

The same has happened to TCP-- middleboxes assume to know things about the
protocol and hinder deployment of features.

Non http1 plaintext on port 80 today doesn't work because proxies developed
expectations about what is going to traverse port 80-- namely a subset of
http1.

-=R
 On Nov 14, 2013 10:51 AM, "Bruce Perens" <[email-masked]> wrote:

>  On 11/14/2013 12:21 PM, Roberto Peon wrote:
>
>
> plaintext works
> Gosh, how badly that dumb Tim B-L failed because he didn't encrypt from
> the very start. The web might have been a success if he'd just listened to
> you. :-)
>
> Plaintext works if you aren't attempting to subvert the entire protocol by
> tunneling through it.
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 13:14:25 -0800

Seems mostly reasonable to me, though the MUSTs here are unenforceable.
-=R
On Nov 14, 2013 10:51 AM, "Michael Sweet" <[email-masked]> wrote:

> All,
>
> A proposal:
>
> 1. Include a discussion of proxy issues inherent in running HTTP/2.0 over
> plaintext: unreliable, undiscoverable, etc.
>
> 2. Include a discussion of common TLS issues - mostly pointers to the
> appropriate RFCs - that honestly talks about the concerns that have been
> expressed on this list.
>
> 4. Place a requirement on public-facing HTTP/2.0 servers: MUST NOT
> advertise HTTP/2.0 support in response headers, MUST NOT support HTTP/2.0
> upgrade. This defines a concrete way to actually “enforce” the use of
> HTTP/2.0 w/TLS *or* HTTP/1.1 w/o TLS (depending on the client/network
> capabilities) instead of hand waving and putting the onus on clients to
> guess whether a connection is local or over the public web.
>
> 5. Define/reference a mechanism that allows a HTTP server to advertise
> that it supports access via https:// - there is at least one draft for
> this, but this allows a client/user agent to opportunistically use https://over http://.
> (For the general case this may not be needed - try connecting on port 443
> first, or in parallel with port 80…)
>
>
> Thoughts?
>
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 14 Nov 2013 21:53:52 +0000

actually I agree with this.

That's why I suggested a long time ago we should look at another port 
number for http2.  100 is available.

I know there is an enormous amount of pain with this path, but it could 
still be less than the current path.

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Julian Reschke" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>; "Bruce Perens" 
<[email-masked]>; "Stephen Farrell" <[email-masked]>
Sent: 15/11/2013 9:25:22 a.m.
Subject: Re: HTTP 2.0 mandatory security vs. Amateur Radio
>we want, but it won't happen since it is not reliable, and the nature 
>of that unreliability is not predictable.
>

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 14:57:00 -0800

On Thu, Nov 14, 2013 at 1:53 PM, Adrien de Croy <[email-masked]> wrote:
> That's why I suggested a long time ago we should look at another port number
> for http2.  100 is available.

+1. HTTP/2 is a fundamentally new protocol. Attempting to stuff it
over port 80 or even 443 is a mistake. That's why we have different
ports in the first place, isn't it? Quit violating the basic design
principles of the underlying layers and suddenly the problem gets a
lot easier to solve... it helps simplify the upgrade path also.

- James

---

From: Roland Zink <[email-masked]>
Date: Fri, 15 Nov 2013 00:11:22 +0100

we can wish of a secure web, but experience from my last hotel stay is 
that secure web only worked after trying to do an insecure request. So 
reality is secure web doesn't work reliably.

Roland

On 14.11.2013 21:21, Roberto Peon wrote:
> deploying plaintext works (yes, ignoring the pervasive multi-party 
> surveillance), but it does little to change reality where it does NOT 
> work reliably.
>
> -=R
>
> On Nov 14, 2013 8:49 AM, "James M Snell" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Nov 14, 2013 at 10:40 AM, Julian Reschke
>     <[email-masked] <mailto:[email-masked]>> wrote:

---

From: David Morris <[email-masked]>
Date: Thu, 14 Nov 2013 16:16:55 -0800 (PST)

On Thu, 14 Nov 2013, Bruce Perens wrote:

>       We can wish honey dreams all day and night long of a web where deploying plaintext works
> 
> Gosh, how badly that dumb Tim B-L failed because he didn't encrypt from the very start. The web might have
> been a success if he'd just listened to you. :-)
> 
> Plaintext works if you aren't attempting to subvert the entire protocol by tunneling through it.

Yeah, I've been doing web work for 18+ years and this is the first claim 
I've seen that plain text makes the web unreliable. What I know for sure
is that adding certficate management has filled my experience with
headaches from a server administrator's perspective.

There are products that subvert ssl/tls because the controlling interested
parties won't allow their networks to be subjected to unispectable
traffic.

I'm tired of hearing about pervasive snooping by governments where our
commercial providers are busy scanning email traffic after it is
in their environment. Encryption isn't going to make my web experience
more reliable, my empirical evidences is that we'll just have one more
thing to cause end user confusion and frustration.

Dave Morris

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 14 Nov 2013 16:28:50 -0800

On Thu, Nov 14, 2013 at 4:16 PM, David Morris <[email-masked]> wrote:

> the very start. The web might have
> I've seen that plain text makes the web unreliable.

​Plain-text HTTP/1 is reliable (as Roberto said).  However plain-text of
any other protocol on port 80 (WebSockets, HTTP/2.x etc) is *not* reliable
because of middle boxes that attempt to process that traffic as HTTP/1.

> What I know for sure

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 16:41:01 -0800

On 11/14/2013 04:28 PM, Ryan Hamilton
wrote:

​Plain-text HTTP/1 is reliable (as
Roberto said).  However plain-text of any other protocol
on port 80 (WebSockets, HTTP/2.x etc) is *not* reliable
because of middle boxes that attempt to process that
traffic as HTTP/1.

Nothing new will ever work unless we tunnel it opaquely through port
443.

And who thinks this is sustainable?

We should either work out how we can go forward, or put the phone
company back in charge and get everything from one source again.

Thanks

Bruce

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 15 Nov 2013 14:28:25 +0900

> Yes. What we disagree on what that means for HTTP: URIs.

Yes. And on top of that, "the spirit of the room" is not what decides in 
IETF WGs. It's the discussion on the mailing list. And this discussion 
doesn't look conclusive at all so far to me.

Regards,   Martin.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 21:38:10 -0800

On Nov 14, 2013 8:24 AM, "Bruce Perens" <[email-masked]> wrote:
>
> On 11/14/2013 09:49 AM, Roberto Peon wrote:
>>
deployed: http1
>
> This isn't realistic unless the HTTP 2 specification makes support of
HTTP 1 mandatory. Which of course is silly.
>> There was near unanimity at the plenary that we should do something
about pervasive monitoring
>
> You had a humming vote to give yourselves the new mission of curing
social and political ills rather than technical ones, by inflicting a
mandatory encryption requirement on everyone, everywhere? It sounds like a
big over step.

You are putting words in people's mouths, or at least doing some liberal
coloring outside the lines.

We know that there is pervasive monitoring by many disparate parties.

What do you propose to do about it, or are you proposing that this is
desirable?

>
>
> Let's make this more clear and ignore the Amateur Radio issue for now. I
don't wish to be forced into concealment in my normal operations on the
Internet.

Then don't browse any site which uses or requires https? Or, use a browser
which sticks to a plaintext protocol?
Why is this difficult?

>
>
> Nor do I wish to have traffic over my personal network which I can not
supervise.

You should probably close off all unknown, non-plaintext ports, or install
a MITM for the SSL stuff.

> Unfortunately, there are a lot of operating systems and applications that
I have not written which use that network. When I can't see the contents of
their network traffic, it is more likely that traffic is being used to
eavesdrop upon me. Surrounding that traffic with chaff by requiring
encryption of _all_ HTTP traffic means that this hostile encrypted traffic
will be impossible to find.

Sure, there is most definitely a tradeoff between ensuring privacy across
the open net and being able to look into all streams.
What I don't see, however, is how you will ever have enough time to
understand all of the interactions which are ongoing on your network--
steganography is just too easy, even for plaintext.

>> Even were that not the case, websites are changing to https for various
other reasons
>
> That's fine, because it's their choice or the users choice. Not yours.

Yes? And what is proposed is still that...

-=R

---

From: Mike Belshe <[email-masked]>
Date: Thu, 14 Nov 2013 22:01:10 -0800

On Thu, Nov 14, 2013 at 10:23 AM, Bruce Perens <[email-masked]> wrote:

> This isn't realistic unless the HTTP 2 specification makes support of HTTP
> 1 mandatory. Which of course is silly.
>
> pervasive monitoring
> You had a humming vote to give yourselves the new mission of curing social
> and political ills rather than technical ones, by inflicting a mandatory
> encryption requirement on everyone, everywhere? It sounds like a big over
> step.
>
>
> don't wish to be forced into concealment in my *normal operations on the
> Internet.*
>
>
> supervise. Unfortunately, there are a lot of operating systems and
> applications that I have not written which use that network. When I can't
> see the contents of their network traffic, it is more likely that traffic
> is being used to eavesdrop upon me. *Surrounding that traffic with chaff
> by requiring encryption of _all_ HTTP traffic means that this hostile
> encrypted traffic will be impossible to find.*
>
>

Bruce -

I'm not going to win you over.  But I will try anyway.  Let's split this
into two questions:

   1) Should we be striving for more communications privacy and security in
HTTP at all?

   2) Is mandatory security a good step toward that goal?

   3) Is TLS a good step toward that goal?

Regarding #1:

General users can't tell when they should expect have security on or off.
Many security usability studies have shown this.   Regardless of how you
feel about TLS or encryption or authentication, you probably agree that in
general, we should make the internet "just work" for people without them
having to know, "gee, is this security level the right one for me?"

I've spent a lot of time researching this, as have many others on this
list.  Our conclusion is that the only way to help them is to have
everything encrypted all the time.  The details of 128bit keys/certificate
expiration/server authenticated/TLS1.0/blah blah blah are subtleties that
Internet users today can't be expected to understand before going online.

This is very different from HTTP of yesteryear.  The malware present, the
bad actors present, and the volume of users online without strong technical
depth have radically changed since HTTP/1.1 was drafted 15 years ago.

Hopefully we agree that HTTP should be doing this and can stop debating
"but I want my open network for me in my house".  You're an expert.  You
can figure something out that you like, no matter what protocol choices we
make.

Regarding #2:

A lot of us on this list have studied HTTP and security and how to protect
general internet users today.

Our conclusion is that the only way to protect them is to have security on
all the time.  Users can't be expected to differentiate when it is the
right level - it needs to always be the right level.   And the website
operators, they don't know what a given user needs to encrypt/make
private/secure either.  There are obvious cases, like banking info, where
it is clear we all want to encrypt.  But other cases, this is gray.  The
only answer which always works is to simply encrypt all the time.  I'm not
really open to counter proposals on this - we've been researching this and
come to this conclusion slowly and deliberately over the last 10 years.

Regarding #3:

TLS is not as easy as it could be.  I agree.  This is in part because we
allow website owners that are technical enough to deploy TLS to not do so.
  Its also an aging system that is in need of an update.

It will get addressed.  But it is far better than nothing.  MITM is
happening already, so we don't have to worry about instigating that.

But to accomplish #1 and #2 above, we need to start taking steps to protect
the users.  We can't improve the security in HTTP until we agree to PUT
some basic security into HTTP.  And right now, the only option on the table
to do so is TLS.

It'll be a little painful.  It won't be for everyone, and a few sites will
opt to keep with HTTP/1.1, just like 10 years ago when a few devices/sites
decided to keep with HTTP/1.0.

It will be 15 years before we get to take another shot at HTTP to add
security into it.   The timing is literally do it now, or for a lot of us
on this list, not in our lifetimes...

Mike

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 07:26:48 +0100

> steganography is just too easy, even for plaintext.

You assume all attacks are the work or elite hackers here to get you.

The mundane truth is most attacks are the result of developer shortcuts
put there for convenience without thinking about the side-effects or user
privacy. They are usually not hidden in any way, all you have to do is
look (assuming the protocol does no cloak them by default).

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 07:33:55 +0100

> expectations about what is going to traverse port 80-- namely a subset of

And that is normal and sane and any successful spec will have the same fate.

No spec is ever implemented 100% on the market, because spec authors do
not have 100% hindsight, and spec implementors do not bother with the
parts they find out have little relevance in actual use.

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 15 Nov 2013 07:47:09 +0100

On Thu, Nov 14, 2013 at 04:28:50PM -0800, Ryan Hamilton wrote:
> ???Plain-text HTTP/1 is reliable (as Roberto said).  However plain-text of

As a *subset* of HTTP/1. Those that attempted to process that traffic as
HTTP/1 do not cause any issues since the protocol explicitly permits these
things.

The CONNECT method is used to open tunnels through proxies and all proxy
users who browse in HTTPS use it. Upgrade does the same with the origin
server instead of a proxy, and with a protocol that is advertised. If
your middle box correctly implements these, then your HTTP/1 is reliable
through this box. And fortunately there are a fair number which do it
right.

Willy

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 22:57:51 -0800

What is your threat model?

-=R

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 23:05:25 -0800

The technical problem is that entities are attempting to be helpful
(sometimes attempting to help the users, and some attempt to help
themselves), and are either failing to adapt with the protocol, or failing
to properly implement it.
Given that putting everything under one roof is infeasible/impossible (the
internet spans many different jurisdictions/countries), and given that we
cannot dictate what people deploy or not, the one technical approach that
has the highest chance of success is the one where content is encrypted.
Do I love this? Nah. But I've been unable to come up with a better plan
that would work. Can you come up with a plan that will work reliably?

-=R

On Thu, Nov 14, 2013 at 4:41 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/14/2013 04:28 PM, Ryan Hamilton wrote:
>
>
>  Plain-text HTTP/1 is reliable (as Roberto said).  However plain-text of
> Nothing new will ever work unless we tunnel it opaquely through port 443.
>
> We should either work out how we can go forward, or put the phone company
> back in charge and get everything from one source again.
>
>     Thanks
>
>     Bruce
>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 08:07:20 +0100

Le Ven 15 novembre 2013 07:47, Willy Tarreau a écrit :

> users who browse in HTTPS use it.

Which makes it a security nightmare, since its allows tunneling any
protocol without control and there are products on the market that
advertise the ability of using connect to bypass any firewall rule.

Thus I resent pretending that connect makes http reliable since it main
point today seems to be to tunnel random non-http junk through security
equipments.

(and I know any encrypted payload by nature can not be controlled but
there is a difference between accepting encrypted bodies inside http
frames with http signalling and tunnelling whole protocols pretty much
unchanged)

-- 
Nicolas Mailhot

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 23:08:25 -0800

On 11/14/2013 10:01 PM, Mike Belshe
wrote:

1) Should we be striving for more communications
privacy and security in HTTP at all?

You have an opportunity, IMO, to do just one important thing. And
that is to specify that all web servers SHOULD allow access to their
normally-served pages using an https URL, and that a browser that
tries https first should succeed. Of course many servers do this
today, we just want something closer to all of them to do
so.

If you do that, the browser developers can take things the rest of
the way. They can leave https as the preferred method by default and
still allow the user some control over that.

2) Is mandatory security a good step toward that
goal?

The problem with mandatory is that some of you seem to believe that
you have to produce the entire solution by yourselves. You are not
leaving the browser makers an option that they would gladly take if
you simply allowed them to do so without requiring it. You are not
leaving an option for those cases where it really is appropriate to
turn security off. I think you have to enable a solution to the
problem, not require it.

TLS works. But the words "transport layer" are a lie. It's an
application and presentation layer protocol. It seems to me that
it's an interim band-aid for a lower-layer problem. I think you
should leave some room for that lower-layer problem to be solved and
for HTTP to be used without encyption at a high layer once it is.

TLS is also inappropriate for resource URLs, for example image files
and javascript. Caching really should work for those things, and
encryption serves no purpose when applied to an immutable public
resource.

This is very different from HTTP of yesteryear.  The
malware present, the bad actors present, and the volume of
users online without strong technical depth have radically
changed since HTTP/1.1 was drafted 15 years ago.

Yes, the cost of success.

I am thinking back to why the Tim B-L version of the web was a
success when others were not. I think it's because Tim didn't insist
that it be an entire solution. Imagine if he'd tried to engineer in
a revenue system like Ted Nelson. He would have gotten nowhere. But
Tim instead left it to other people to figure out how to make money
from the web, and simply gave them sufficient tools to do so.
Similarly, you need to give us sufficient tools to have security
across all web sites. You don't have to force us to use them.

Hopefully we agree that HTTP should be doing this and
can stop debating "but I want my open network for me in my
house".  You're an expert.  You can figure something out
that you like, no matter what protocol choices we make.

Nope. If tools that I can't control have mandatory encryption there
is little that I can do. Regardless of what an expert I am.

And the website operators, they don't know what a given user
needs to encrypt/make private/secure either.

I understand about the users not knowing what is appropriate. But
what you are saying here is that nobody but you and perhaps your
friends on the HTTP protocol team can ever be competent to make this
decision or can be trusted to do so. Even people who would
reasonably have the responsibility, like web site operators or
browser developers, can not be given the chance to act
appropriately. You must decide for all of them.

If this were to be the position of the HTTP working group in
general, the problem would be solved because nobody would take them
seriously.

Thanks

Bruce

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 23:13:54 -0800

On 11/14/2013 12:25 PM, Roberto Peon
wrote:

Then stop. We understand that the internet is broken. The real
debate about that is whether we should work around the breakage by
using encrypted tunnels for everything, or fix it.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 15 Nov 2013 08:15:05 +0100

Hi Roberto,

> What do you propose to do about it, or are you proposing that this is

A quick point here, yes there is this monitoring and yes we'd like to
get rid of it. But it seems amazing to me to see that people forget
the most important part : the only value of the information to collect
is on HTTPS and this monitoring happens mostly on HTTPS. End users'
gmail accesses get sniffed and have been for a while now in certain
countries. To the best of my knowledge, gmail is https-only, right ?
So by migrating all non-important web sites from HTTP to HTTPS, we
won't fix this, at most we'll add more noise to the sniffers, except
that it's trivial to pick the domains or addresses they're interested
in. Again, the only short-term *fix* to this situation is to make the
user aware of what's happening. The UI could display in real time at
the bottom of the page the name of the cert issuer for example. And
we must make it impossible to click through "I accept the risk" since
it provides no additional security over plain-text.

Best regards,
Willy

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 08:16:05 +0100

> What is your threat model?

The threat model is
1. developer that makes information leak trough incompetence, laziness,
sloppiness or greed (cf all the info your average android app wants to
access)
2. attacker that does not need to penetrate target anymore can just
collect the leaked info at endpoints (see also: Snowden)
3. protocol that prevents anyone doing anything about it by default

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 15 Nov 2013 08:20:19 +0100

> advertise the ability of using connect to bypass any firewall rule.

Yes for sure, just like Upgrade. But most of the MITM boxes that make
port 80 unreliable are caches, load balancers and web compressors.
They're only there to reduce internet access costs, not for security,
so that's not a problem.

However I've already heard an ISP ask me if it was possible to transparently
intercept https using haproxy because the increase in https traffic was
reducing the efficiency of their caches to a point of becoming business
critical. I said no we can't do that, but I'm quite convinced they found
a solution since then.

Willy

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 08:22:34 +0100

> that would work. Can you come up with a plan that will work reliably?

Be honest, use a different port and let people accept it if they're
comfortable with your solution and their equipments can deal with the
result.

This is the only solution that will get you reliable adoption (trying to
enter via the back door is not reliable, it only works till the watchman
notices your little trick and puts a lock on it, so stuff will break at
unpredictable times even if it passed at first)

-- 
Nicolas Mailhot

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 23:24:20 -0800

A workable alternative to what we have today should, when deployed widely,
achieve success rates no lower than what we experience today.
Proposing such an alternate mechanism would be constructive.
Until such is proposed, there is no means to 'fix it'!

-=R

On Thu, Nov 14, 2013 at 11:13 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/14/2013 12:25 PM, Roberto Peon wrote:
>
> Then stop. We understand that the internet is broken. The real debate
> about that is whether we should work around the breakage by using encrypted
> tunnels for everything, or fix it.
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 23:25:38 -0800

You are saying that we should use a port other than :443 for https traffic?
... why?
What backdoor are we talking about?
-=R

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 23:30:22 -0800

On 11/14/2013 11:05 PM, Roberto Peon
wrote:

Given that putting everything under one roof is
infeasible/impossible (the internet spans many different
jurisdictions/countries), and given that we cannot dictate what
people deploy or not, the one technical approach that has the
highest chance of success is the one where content is encrypted.

Do I love this? Nah. But I've been unable to come up
with a better plan that would work. Can you come up with a plan
that will work reliably?

I definitely don't want to go back to Ma Bell running everything.
But it seems to me that just saying that an encrypted tunnel to one
port must be the solution for everything is a complete abdication of
leadership. Instead of being the protocol designers of the internet,
we become the rats in the walls who sneak all of our new inventions
through a little encrypted hole in what we made.

We broke the internet. It was because of our tremendous success. It
grew so big that its size and inertia froze it and made further
protocol development impossible.

Getting out of this problem starts with admitting it, publicly, to
everyone. It then will be necessary to chart the requirements that
will prevent this from happening again, and then to promote and
certify the implementations of those recommendations.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 23:32:23 -0800

For 1,2: How is this not orthogonal to the rest of the discussion?
For 3: I'm assuming you mean because the data is encrypted. You can MITM
this.

Just to be sure we're all on the same page here (because it seems that
we're not):.
  As I understand it, the proposal is:
    For web activity on the "open internet", if the scheme is https,
attempt to use http/2 over an encrypted, authenticated channel.
    For web activity on the "open internet", if the scheme is http, use
http/1 over an unencrypted, plaintext channel.
    For activity on a private network: use any combination of
{authenticated, unauthenticated}{encrypted, unencrypted}{http2,http1} you
desire.

Is there an objection to this?
-=R

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Nov 2013 23:36:13 -0800

No objection, but in Vancouver, there seemed to be quite a few voices
saying that trying for opportunistic encryption, even of http:-scheme
connections, was a good idea if technically achievable. I’d certainly be in
favor.

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 23:48:13 -0800

On 11/14/2013 11:32 PM, Roberto Peon
wrote:

For 1,2: How is this not orthogonal to the rest of
the discussion?

For 3: I'm assuming you mean because the data is
encrypted. You can MITM this.

Just to be sure we're all on the same page here
(because it seems that we're not):.

For web activity on the "open internet", if
the scheme is https, attempt to use http/2 over an encrypted,
authenticated channel.

For web activity on the "open internet", if the scheme is
http, use http/1 over an unencrypted, plaintext channel.

For activity on a private network: use any
combination of {authenticated, unauthenticated}{encrypted,
unencrypted}{http2,http1} you desire.

Yes. It's stating that the only possible use of unencrypted http
must be via http/1.1 . It's either assuming that we must support
http/1.1 forever, in which case that perpetual support should be
part of the http 2 specification; or it's assuming that http/1.1
will wither and that this will eventually force everyone to use
encrypted traffic always.

Neither of these seem optimal. The proposal ignores the fact that
the vast majority of web traffic is immutable public content for
which encryption serves no real purpose, and that the transmission
of this content may benefit from innovations in http/2 other than
encryption.

By the way, when I really feel the need to encrypt something, I use
the one-time pad. Depending on anything else is optimistic.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 23:49:59 -0800

I don't even think we can get the right people to admit that it is broken
(there are a lot of vested interests who have strong incentives to maintain
status quo).

But I do agree-- the internet today is broken in many respects:
  you can't deploy anything other than a subset of http/1.1 on port 80
reliably
  middleboxes prevent better TCP implementation deployments (or make it
substantially more difficult to do) by enforcing rules that are not
actually defined for TCP
  the packet forwarding plane for the internet provides poor (if any) flow
isolation, resulting in either high packet loss (small buffers), or
bufferbloat (large buffers).
  only a few well-known ports actually are reliable
  .. and I can go on and on and on :)

I'm an engineer. I don't mind admitting to problems, nor do I particularly
mind being wrong when it implies that a better understanding has been
achieved (or a better outcome).

When I think about how we got here, I'm fairly certain that there is no
MUST we could put into a document or spec, and there is no social
engineering that would have prevented us from reaching the state that we're
in today w.r.t. middleboxes.
That implies that the solution-space is limited to things that we can
ensure mechanically.
-=R

On Thu, Nov 14, 2013 at 11:30 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/14/2013 11:05 PM, Roberto Peon wrote:
>
>  Given that putting everything under one roof is infeasible/impossible
> (the internet spans many different jurisdictions/countries), and given that
> we cannot dictate what people deploy or not, the one technical approach
> that has the highest chance of success is the one where content is
> encrypted.
>  I definitely don't want to go back to Ma Bell running everything. But it
> seems to me that just saying that an encrypted tunnel to one port must be
> the solution for everything is a complete abdication of leadership. Instead
> of being the protocol designers of the internet, we become the rats in the
> walls who sneak all of our new inventions through a little encrypted hole
> in what we made.
>
> We broke the internet. It was because of our tremendous success. It grew
> so big that its size and inertia froze it and made further protocol
> development impossible.
>
> everyone. It then will be necessary to chart the requirements that will
> prevent this from happening again, and then to promote and certify the
> implementations of those recommendations.
>

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 23:58:48 -0800

On 11/14/2013 11:49 PM, Roberto Peon
wrote:

When I think about how we got here, I'm fairly
certain that there is no MUST we could put into a document
or spec, and there is no social engineering that would have
prevented us from reaching the state that we're in today
w.r.t. middleboxes.

It seems to me that the major employment of firewall rules is to
protect from the unknown. We don't know what legitimate traffic
would ever be on that port, so we block it.

It is a solvable task to teach that this practice breaks the
internet, and to promote better practices. I don't see that it would
be impossible to do this with MUST rules in a specification,
although that isn't the only means available.

The problem of port 80 traffic being handled incorrectly becomes
much less important if other ports are available.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 00:00:59 -0800

There is explicitly an option for unencrypted HTTP/2, but not over the
"open" internet, since that is known/provent to be unreliable.

And in my personal opinion, HTTP is a poor mechanism for cached content: it
allows for a very limited distribution model and (amongst other things)
doesn't adequately differentiate between resources that should be public,
but verifiably unmodified, and private resources.
I wish that we had a different protocol (and I've been talking about this
for a while actually) for public, cacheable content. I've proposed such in
the past, but don't have the bandwidth to work on it until HTTP/2 is done.
The basics of the (now old, but still unimplemented) idea there are,
however, that everything is a subset of peer-to-peer, and thus the large
part of the innovation that should be done is in the policy about how the
data is to be distributed in a potentially peer-to-peer network
As an example, imagine a policy which could indicate that, for any
arbitrary byterange of a resource first try from the origin, then the local
ISP supernode, and if those fail, try from peers.
In this imagined world/protocol, the SlashDot effect would be a thing of
the past, even for those sites not using a CDN, since the more users there
were of a site, the more peers there would be for the content.
... but this is waaaaay off topic now.

-=R

On Thu, Nov 14, 2013 at 11:48 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/14/2013 11:32 PM, Roberto Peon wrote:
>
>  Yes. It's stating that the only possible use of unencrypted http must be
> via http/1.1 . It's either assuming that we must support http/1.1 forever,
> in which case that perpetual support should be part of the http 2
> specification; or it's assuming that http/1.1 will wither and that this
> will eventually force everyone to use encrypted traffic always.
>
> Neither of these seem optimal. The proposal ignores the fact that the vast
> majority of web traffic is immutable public content for which encryption
> serves no real purpose, and that the transmission of this content may
> benefit from innovations in http/2 other than encryption.
>
> By the way, when I really feel the need to encrypt something, I use the
> one-time pad. Depending on anything else is optimistic.
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Nov 2013 16:11:16 +0800

And that’s reflected in the issues list:
  https://github.com/http2/http2-spec/issues/315

It’s on hold because we don’t yet have any implementer interest in it; if that changes, we’ll talk about it again. Informally, folks have said that they want to see how the HTTPS approach worked out first.

On 15 Nov 2013, at 3:36 pm, Tim Bray <[email-masked]> wrote:

> No objection, but in Vancouver, there seemed to be quite a few voices saying that trying for opportunistic encryption, even of http:-scheme connections, was a good idea if technically achievable. I’d certainly be in favor. 
> 
> 
> For 3: I'm assuming you mean because the data is encrypted. You can MITM this.
> 
> Just to be sure we're all on the same page here (because it seems that we're not):.
>     For web activity on the "open internet", if the scheme is https, attempt to use http/2 over an encrypted, authenticated channel.
>     For web activity on the "open internet", if the scheme is http, use http/1 over an unencrypted, plaintext channel.
>     For activity on a private network: use any combination of {authenticated, unauthenticated}{encrypted, unencrypted}{http2,http1} you desire.
>  
> On Thu, Nov 14, 2013 at 11:16 PM, Nicolas Mailhot <[email-masked]> wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 00:14:01 -0800

On Thu, Nov 14, 2013 at 11:58 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/14/2013 11:49 PM, Roberto Peon wrote:
>
>
> It seems to me that the major employment of firewall rules is to protect
> from the unknown. We don't know what legitimate traffic would ever be on
> that port, so we block it.
> It is a solvable task to teach that this practice breaks the internet, and
> to promote better practices. I don't see that it would be impossible to do
> this with MUST rules in a specification, although that isn't the only means
> available.
>
> The problem of port 80 traffic being handled incorrectly becomes much less
> important if other ports are available.
>

Sure, I agree with the premise that we'd be in a better state if ports were
available.
But that seems like an educational problem, not a mechanical problem, and
as such I am dubious about it being solvable in any near or medium-term
timeframe (it takes 5+ years to get hardware replaced normally, I think?),
assuming it is solvable at all.
(Looking at education for even simpler things, apparently education is an
extremely difficult problem...)

I am in no way opposed to people trying to go down that path, of course...

-=R

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Nov 2013 09:39:58 +0100

On 2013-11-15 09:00, Roberto Peon wrote:
> And in my personal opinion, HTTP is a poor mechanism for cached content:
> it allows for a very limited distribution model and (amongst other
> things) doesn't adequately differentiate between resources that should
> be public, but verifiably unmodified, and private resources.
 > ...

Cache-Control?

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 00:43:12 -0800

Cache-control isn't rich enough to express this yet.
The mechanism itself is less interesting than figuring out the set of
caching policy primitives-- once that exists, and once a backwards
compatible way of specifying how to access such resources from a standard
HTML page exists (new schemes probably don't/won't work), then we're ready
to roll!
-=R

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 15 Nov 2013 11:47:00 +0100

> Yes. What we disagree on what that means for HTTP: URIs.

I would like to know the answer for that as well. By using https instead of http you don't just change the bits on the wire but also a lot of other stuff (at least) in browsers. For example referrers are not sent anymore, information in form fields isn't stored anymore for autocompletion etc. etc. I think it would be very beneficial to still keep this distinction of sensitivity/confidentiality. Whether traffic to http URIs is then (optimistically) encrypted or not, doesn't really matter to the average end user.

--
Markus Lanthaler
@markuslanthaler

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 16 Nov 2013 02:08:53 +1300

> because of middle boxes that attempt to process that traffic as HTTP/1.

Which is due to RFC 2616 section 1.4 paragraphs 3 & 4.

Anyone who does not understand that needs to read that section and
familiarize themselves with the second message flow diagram. In
particular the purpose and operation of the stages labeled A, B, C.

Amos

---

From: Michael Sweet <[email-masked]>
Date: Fri, 15 Nov 2013 10:48:26 -0500

Roberto,

On Nov 15, 2013, at 3:00 AM, Roberto Peon <[email-masked]> wrote:
> There is explicitly an option for unencrypted HTTP/2, but not over the "open" internet, since that is known/provent to be unreliable.

I have a real problem with trying to spec “don’t do this over the open Internet”.

And IIRC the IETF frowns on protocols that special-case local usage - the assumption that Internet access to http:// URIs usually occurs through proxies while https:// URIs are “safe” has already been shown to be invalid, and I suspect that organizations that deploy proxies may not limit their use to “outside” traffic, so local access may indeed have the same issues as remote, for both http:// and https:// URIs.

The challenge, then, is how we can work with the HTTP/1.1 rules for proxies instead of trying to work around them.  Otherwise we really do have a completely new protocol and need to treat it as such (new port number, http2:// URIs, etc.)

> 
> And in my personal opinion, HTTP is a poor mechanism for cached content: it allows for a very limited distribution model and (amongst other things) doesn't adequately differentiate between resources that should be public, but verifiably unmodified, and private resources.
> I wish that we had a different protocol (and I've been talking about this for a while actually) for public, cacheable content. I've proposed such in the past, but don't have the bandwidth to work on it until HTTP/2 is done.
> The basics of the (now old, but still unimplemented) idea there are, however, that everything is a subset of peer-to-peer, and thus the large part of the innovation that should be done is in the policy about how the data is to be distributed in a potentially peer-to-peer network
> As an example, imagine a policy which could indicate that, for any arbitrary byterange of a resource first try from the origin, then the local ISP supernode, and if those fail, try from peers.
> In this imagined world/protocol, the SlashDot effect would be a thing of the past, even for those sites not using a CDN, since the more users there were of a site, the more peers there would be for the content.
> Yes. It's stating that the only possible use of unencrypted http must be via http/1.1 . It's either assuming that we must support http/1.1 forever, in which case that perpetual support should be part of the http 2 specification; or it's assuming that http/1.1 will wither and that this will eventually force everyone to use encrypted traffic always.
> 
> Neither of these seem optimal. The proposal ignores the fact that the vast majority of web traffic is immutable public content for which encryption serves no real purpose, and that the transmission of this content may benefit from innovations in http/2 other than encryption.
> 
> By the way, when I really feel the need to encrypt something, I use the one-time pad. Depending on anything else is optimistic.
>

---

From: James M Snell <[email-masked]>
Date: Fri, 15 Nov 2013 07:57:45 -0800

I find myself emphatically agreeing with pretty much everything Michael
says in this thread.
On Nov 15, 2013 7:50 AM, "Michael Sweet" <[email-masked]> wrote:

> And IIRC the IETF frowns on protocols that special-case local usage - the
> assumption that Internet access to http:// URIs usually occurs through
> proxies while https:// URIs are “safe” has already been shown to be
> invalid, and I suspect that organizations that deploy proxies may not limit
> their use to “outside” traffic, so local access may indeed have the same
> issues as remote, for both http:// and https:// URIs.
>
> The challenge, then, is how we can work with the HTTP/1.1 rules for
> proxies instead of trying to work around them.  Otherwise we really do have
> a completely new protocol and need to treat it as such (new port number,
> http2:// URIs, etc.)
>
>
> it allows for a very limited distribution model and (amongst other things)
>>  Yes. It's stating that the only possible use of unencrypted http must
>> be via http/1.1 . It's either assuming that we must support http/1.1
>> forever, in which case that perpetual support should be part of the http 2
>> Neither of these seem optimal. The proposal ignores the fact that the
>> vast majority of web traffic is immutable public content for which
>> encryption serves no real purpose, and that the transmission of this
>> content may benefit from innovations in http/2 other than encryption.
>>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Nov 2013 16:59:56 +0100

On 2013-11-15 16:48, Michael Sweet wrote:
> Roberto,
>
> On Nov 15, 2013, at 3:00 AM, Roberto Peon <[email-masked]
> <mailto:[email-masked]>> wrote:

Indeed. In particular as what's "known" to be unreliable today might 
become more reliable in the future (given the right incentives).

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 17:02:28 +0100

> 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

---

From: Bruce Perens <[email-masked]>
Date: Fri, 15 Nov 2013 09:10:13 -0800

On 11/15/2013 08:02 AM, Nicolas Mailhot
wrote:

Agreed.

Paul Vixie sent me this:

default=closed firewalls were known about fairly early
on. this consequence was foreseeable.

"I don't know what apps and protocols humanity will speak 50 years
from now, but we will call it the Internet, and it will run over
TCP port 80."

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 09:18:06 -0800

I don't have a problem with not speccing it.

I'd just turn it off for any servers that I could influence since I don't
want to lose users.

We can frown on guidance like this, but, well, we have broken the internet
or allowed it to become broken, and we need solutions today and tomorrow
that will work reliably.

It really all comes down to the issue if providing a service to users
reliably.

I am not interested in attempting to work with implicit proxies- it is too
difficult.
I AM interested, however in working with explicit proxies, and even
submitted and contributed to a couple of drafts on the topic.

-=R

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Nov 2013 17:24:29 +0000

Hi,

On 11/15/2013 05:18 PM, Roberto Peon wrote:
> and even

I don't know if you mean a TLS MITM proposal or something
else.

In the former case, please accompany any such proposal with
an analysis of the set of 176 RFCs [1] that reference 5246
and the 91 that refer to 4246 [2] and the 167 that refer to
2246 [3] to demonstrate that MITM'ing all of those is a good
and safe plan. And of course that ignores the non-IETF things
that might use TLS, which I'm sure is some medium sized
chunk of the 1573 [4] references that google scholar throws
up.

Thanks, (or rather, "No, thanks"),
S.

[1] http://www.arkko.com/tools/allstats/citations-rfc5246.html
[2] http://www.arkko.com/tools/allstats/citations-rfc4346.html
[3] http://www.arkko.com/tools/allstats/citations-rfc2246.html
[4]
http://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 09:31:22 -0800

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 09:33:43 -0800

Ah, that is unfortunate. I wish that the community had done something then,
if it had been foreseen.
-=R

On Fri, Nov 15, 2013 at 9:10 AM, Bruce Perens <[email-masked]> wrote:

>  On 11/15/2013 08:02 AM, Nicolas Mailhot wrote:
>
>
> default=closed firewalls were known about fairly early on. this
> consequence was foreseeable.
>
> "I don't know what apps and protocols humanity will speak 50 years from
> now, but we will call it the Internet, and it will run over TCP port 80."
>
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 09:38:53 -0800

*sigh*

So, Stephen, do you support using encryption or not, and can we move that
discussion to a separate thread?

-=R

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Nov 2013 17:55:02 +0000

Hiya,

> *sigh*

Sorry to be so predictable:-)

> discussion to a separate thread?

I very much support using encryption.

I'm ok with mnot's plan, if there's work done to
tackle how to get server certs for web sites and
devices, but am worried that'll not happen or
will fail to help.

I'd really liked the idea of http:// URIs via
unauthenticated TLS for HTTP/2.0 and am a bit
sad that's being punted down the road. I do
see that that's complicated for mixed-content,
maybe even fatally complicated.

I'm very very against TLS MITM proposals.

But I do think that's all been said. I hadn't
seen the scale of impact of TLS MITM called out
that way, which is why I posted.

S.

---

From: James M Snell <[email-masked]>
Date: Fri, 15 Nov 2013 11:07:09 -0800

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 <[email-masked]> 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.
>
> despite being far better for the user, this feature was disabled for port 80
> because it was not deployable.
>
> protocols over port 80, and that proved problematic: The most interesting of
> which is probably WebSockets. As mentioned previously this essentially
> doesn't work.
>
> On Fri, Nov 15, 2013 at 8:02 AM, Nicolas Mailhot
> <[email-masked]> wrote:
>>
>>

---

From: Mike Belshe <[email-masked]>
Date: Fri, 15 Nov 2013 11:11:41 -0800

> now, but we will call it the Internet, and it will run over TCP port 80."

More likely port 443 :-)

Mike

---

From: SM <[email-masked]>
Date: Fri, 15 Nov 2013 11:11:23 -0800

>protocol development impossible.

Ok.

>certify the implementations of those recommendations.

History repeats itself.

The decision (if a decision is necessary) about whether HTTP 2.0 
needs mandatory security does not have to be cast in stone.  The 
constraints of today, e.g. amateur radio, might change by the time 
this working group delivers the specification.  There are 
alternatives to satisfy the constraints.  Some of the alternatives 
come up their own sets of problems (e.g. MITM).

Regards,
-sm

---

From: James M Snell <[email-masked]>
Date: Fri, 15 Nov 2013 11:45:51 -0800

This quick exchange between Mike and I accidentally went offlist...
copying it here...

On Fri, Nov 15, 2013 at 11:23 AM, Mike Belshe <[email-masked]> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Nov 2013 11:47:16 -0800

On 15 November 2013 11:11, SM <[email-masked]> wrote:
> The constraints of today, e.g. amateur radio, might change by the time this
> working group delivers the specification.

I hope not.  I wasn't planning on making this a career.  As far as I'm
concerned, HTTP/2.0 ships mid-year 2014 [1].  If we can't sort
ourselves out before then, I might just have to walk away.

--Martin

[1] In the sense that the working group is done.  I'm well aware that
these things have long tails through AD/IESG/IANA/RFC editor, but the
main WG consensus part is the bit I care about most.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 21:06:32 +0100

> What is the something else would you suggest?

I'm not convinced at all using a new port is infeasible. Yes, it would be
devilishly hard for a new corner-case protocol. But the web as a whole is
something else entirely and a new way to access it won't be dismissed so
easily. Of course adoption would take years, you don't replace billions of
web equipments that easily, but it would happen anyway.

That is, provided the protocol actually brings enough on the table to
justify the pain.

For example bittorent provided value for pirates and Linux users and they
authorised in on their equipments. It didn't provide value to anyone else
and was blocked elsewhere.

Websocket, I'm sorry to say, does not bring any value. Its main purpose is
to help developers force the passage of protocols people already blocked,
so of course people will block websockets too (notwithstanding what
websocket developers wish)

So what does the http/2 draft propose today?

1. better latency: that will give you mobile users, gamers and traders
(through web services)

2. encryption: I'm sorry that's an antifeature for all average users.
Encryption is a PITA to use and deploy, it kills caching, it kills
interop, it doesn't remove monitoring by web giants or the NSA, CA
security is questioned, people by and large do not care if most of their
traffic is observed, and you're proposing tanks to access cardboard houses
(most web sites are not ironclad and won't be in the future). Case in
point: ipsec market failure, social network successes.

3. server push: again, an antifeature. People are already bombarded by
advertisements and other stuff they didn't request.

4. new web applications? Who cares, they don't exist now. By all means
enable them but the only thing that will sell your protocol is making
better what people already know and want

And that's all. That's pretty thin to justify the pain if you're not a
mobile operator or a privacy zealot. In fact I suspect it's a net loss so
far. So I'd suggest you need to work more on your sales argument instead
of trying to force people to adopt something they don't need through
technical trickery. It's not as if there are no easy wins out there:

1. caching: http/1 caching is byzantine and not that efficient. You have
ideas on the subject? Wonderful! Everyone loves smaller download times and
less bandwidth use.

2. compression: surely in the past decade the state of the art improved
enough you can add better compression engines as option in http/2?
Terrific! again, everyone loves less bandwidth use (but make it possible
to optionnaly inhibit it for people with CPU constrains)

3. cookies: magnificent! the wg didn't want to discuss this but EU
legislation shows demand exists to fix the cookie hell, and web sites
operators would rather pass their time elsewhere than operating cookie
banners.

4. intermediaries: fix intermediary deployment problems (in particular
paygates) and you fix the hotel/airport/metro station/convention/guest
user situation. Extraordinary! Many people would kill to avoid paying xG
bills when data networks are available, and resort operators only want to
keep away external network leeches.

And there are probably others I forget. Remember, web infrastructure as a
whole represents an heavy investment by many actors. http has been static
for a decade and that's a net plus for most users. Everyone but developers
hates technical change. You need to put a lot on the table to convince
network operators to let you pass. And you need to present it in a single
package "please pay for new equipments and BTW I'll introduce another
change next year so be prepared for another bill" is *not* a seller. So
putting away problems to look at in another revision is not the way to go.

Regards,

-- 
Nicolas Mailhot

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 17 Nov 2013 15:28:59 +1300

> That is, provided the protocol actually brings enough on the table to

Exactly the same arguments apply to staying with port-80 in the first
place. There will be initial pain, but things will straighten out
eventually. Provided the protocol actually brings enough to the table to
justify upgrading/fixing the middleware which is currently problematic.

Additionally, a lot of the firewall and security designs will not have
to be changed.

HTTP/2 as an upgrade to HTTP/1 which works when it works (what was that
80% of the time right now?), but stays HTTP/1 when it doesn't is a major
selling factor.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 08:30:16 +0000

In message <[email-masked]>, Amos Jeffries writes:
>> Le Ven 15 novembre 2013 18:31, Roberto Peon a Ã©crit :
>> 
>> easily.

The same exact thing was said about IPv6, almost 20 years ago.

This argument only applies if you s/new/much improved/

In my not at all humble opinion, the current draft is nowhere near
that.  Ratifying the current fraft on port 100 would be pointless.

>eventually.

The two thing which have started to worry me about staying on port
80 is:

A) HTTP/2.0 benefits will only materialize after a couple of RTT's
   because of the upgrade kabuki dance.

B) HTTP/1.1 infrastructure will be compromised while people iron the
   bugs out of their HTTP/2.0 code.

I'd say that our best shot is:

1) Make HTTP/2.0 simpler to implement than HTTP/1.0 (by eliminating
   and simplifying the semantics, and not adding new complexity.)

2) Make HTTP/2.0 faster than HTTP/1.0 (encoding + mux + pipeline +
   shaving cookies so all requests fit a packet)

3) Avoid time-wasting undecidable political issues (aka: encryption)

4) Define a new port *AND* an upgrade method.

5) Sit back and see if people like it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Nov 2013 11:03:51 +0000

> web equipments that easily, but it would happen anyway.

I'd like to give the firewall view of this. Suppose we get IANA to assign port 100 for HTTP/2. Right now, firewall policies fall into two broad categories:

 1. The lenient, where outbound connections are always permitted, and
 2. The strict, where we don't let anything go either way if we don't understand it. 

Under the lenient policy, HTTP/2 on port 100 would work. Under the strict policy, it won't. I'm sure browsers will do something happy eyeballs-like, and quickly determine that port 80 works and port 100 doesn't and will use the appropriate one, along with the HTTP version that goes with it. So far, so good.

The problem with this, is that the firewalls have some policy as to what is and isn't allowed in HTTP (this is what is marketed as "next generation firewall"), so as soon as web stuff starts going through port 100, administrators will
 1. block port 100, and 
 2. demand that vendors do their inspection on port 100 as well.

The best case scenario, is that firewall vendors quickly create HTTP/2 parsing code, push it into the next versions of their software (known as firmware for some vendors), and then port 100 can be opened as part of "the web" with all the inspection that is done on port 80 today. That drives firewall customers to upgrade, which will make firewall vendors happy to add the support.

The not-quite-best case is where firewall vendors push out an incomplete HTTP/2 parser based on some wild assumptions about what servers and clients will do. That can lead to some strange failure modes. BTW: the same can be said of browser code and server code and caching proxy code, and you'll have a hard time debugging which part of the system is at fault. Luckily, going to port 100 allows the administrator to easily block the port, and push everyone back to HTTP/1.

By having HTTP/2 on port 80 along with port 100, you run a bigger risk of strange results. Connections may succeed, but then firewalls that fail to recognize the upgrade dance will do strange things to the connection once strangeness happens. This is somewhat mitigated by the fact that websockets happened several years ago, so any fairly recent firewalls do recognize (and are able to block) the upgrade dance, so I think the failure rates will not be quite as large as they were a few years ago when websockets first appeared.

On balance, I think deploying HTTP/2 on a new port, and not doing surprising things on port 80 (other than maybe Mark's proposed header saying that HTTP/2 is available on port 100) would be a good thing. Adding opportunistic encryption there (but not on port 80) would also be a good thing, but it's orthogonal to the primary question of how to deploy HTTP/2 in http:// URLs.

Yoav