Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

From: James M Snell <[email-masked]>
Date: Wed, 7 Jan 2015 08:09:00 -0800

While I'm not going to write an essay about it like phk, I will agree that
http/2 is a major disappointment to me as well. There is far too much
needless complexity with far too little overall improvement. The protocol
design feels rushed and unproven. The design process was very one sided
with little real consideration of alternative ideas. Http/2 does little to
nothing to help everyday developers relative to Http/1 and does nothing to
address many of http/1's existing limitations. I have no problem with
publishing the current Http/2 as an Experimental Track RFC and giving
developers a few years to try things out. That would give us time to get
more implementation experience, make refinements, etc before making any
presumption that a true successor to Http/1 is ready for prime time.
Declaring it as a Standards Track feit accompli now would be a mistake.

- James Snell
(speaking strictly as an individual, not as a representative of my employer)
On Jan 7, 2015 7:24 AM, "Poul-Henning Kamp" <[email-masked]> wrote:

> --------
>
> Here are my comments to the HTTP2 proposal:
>
> HTTP/2.0 — The IETF is Phoning It In
> ====================================
>
> Bad protocol, bad politics
>
>
> A very long time ago —in 1989 —Ronald Reagan was president, albeit
> only for the final 19½ days of his term. And before 1989 was over
> Taylor Swift had been born, and Andrei Sakharov and Samuel Beckett
> had died.
>
> In the long run, the most memorable event of 1989 will probably be
> that Tim Berners-Lee hacked up the HTTP protocol and named the
> result the "World Wide Web." (One remarkable property of this name
> is that the abbreviation "WWW" has twice as many syllables and takes
> longer to pronounce.)
>
> Tim's HTTP protocol ran on 10Mbit/s, Ethernet, and coax cables, and
> his computer was a NeXT Cube with a 25-MHz clock frequency. Twenty-six
> years later, my laptop CPU is a hundred times faster and has a
> thousand times as much RAM as Tim's machine had, but the HTTP
> protocol is still the same.
>
> A few days ago the IESG, The Internet Engineering Steering Group,
> asked for "Last Call" comments on new "HTTP/2.0" protocol
> (https://tools.ietf.org/id/draft-ietf-httpbis-http2) before blessing
> it as a "Proposed Standard".
>
> Expectations Will Vary
>
> Some will expect a major update to the world's most popular protocol
> to be a technical masterpiece and textbook example for future
> students of protocol design. Some will expect that a protocol
> designed during the Snowden revelations will improve their privacy.
> Others will more cynically suspect the opposite. There may be a
> general assumption of "faster." Many will probably also assume it
> is "greener." And some of us are jaded enough to see the "2.0" and
> mutter "Uh-oh, Second Systems Syndrome."
>
> The cheat sheet answers are: no, no, probably not, maybe, no and yes.
>
> If that sounds underwhelming, it's because it is.
>
> HTTP/2.0 is not a technical masterpiece. It has layering violations,
> inconsistencies, needless complexity, bad compromises, misses a lot
> of ripe opportunities, etc. I would flunk students in my (hypothetical)
> protocol design class if they submitted it. HTTP/2.0 also does not
> improve your privacy. Wrapping HTTP/2.0 in SSL/TLS may or may not
> improve your privacy, as would wrapping HTTP/1.1 or any other
> protocol in SSL/TLS. But HTTP/2.0 itself does nothing to improve
> your privacy.
>
> This is almost triply ironic, because the major drags on HTTP are
> the cookies, which are such a major privacy problem, that the EU
> has legislated a notice requirement for them. HTTP/2.0 could have
> done away with cookies, replacing them instead with a client
> controlled session identifier. That would put users squarely in
> charge of when they want to be tracked and when they don't want
> to—a major improvement in privacy. It would also save bandwidth and
> packets. But the proposed protocol does not do this.
>
> The good news is that HTTP/2.0 probably does not reduce your privacy
> either. It does add a number of "fingerprinting" opportunities for
> the server side, but there are already so many ways to fingerprint
> via cookies, JavaScript, Flash, etc. that it probably doesn't matter.
>
> You may perceive webpages as loading faster with HTTP/2.0, but
> probably only if the content provider has a global network of
> servers. The individual computers involved, including your own,
> will have to do more work, in particular for high-speed and large
> objects like music, TV, movies etc. Nobody has demonstrated a
> HTTP/2.0 implementation that approached contemporary wire speeds.
> Faster? Not really.
>
> That also answers the question about the environmental footprint:
> HTTP/2.0 will require a lot more computing power than HTTP/1.1 and
> thus cause increased CO2 pollution adding to climate change. You
> would think that a protocol intended for tens of millions of computers
> would be the subject of some green scrutiny, but surprisingly—at
> least to me —I have not been able to find any evidence that the
> IETF considers environmental impact at all —ever.
>
> And yes, Second Systems Syndrome is strong.
>
> Given this rather mediocre grade-sheet, you may be wondering why
> HTTP/2.0 is even being considered as a standard in the first place.
>
> The Answer is Politics
>
> Google came up with the SPDY protocol, and since they have their
> own browser, they could play around as they choose to, optimizing
> the protocol for their particular needs. SPDY was a very good
> prototype which showed clearly that there was potential for improvement
> in a new version of the HTTP protocol. Kudos to Google for that.
> But SPDY also started to smell a lot like a "walled garden" to some
> people, and more importantly to other companies, and politics
> surfaced.
>
> The IETF, obviously fearing irrelevance, hastily "discovered" that
> the HTTP/1.1 protocol needed an update, and tasked a working group
> with preparing it on an unrealistically short schedule. This ruled
> out any basis for the new HTTP/2.0 other than the SPDY protocol.
> With only the most hideous of SPDY's warts removed, and all other
> attempts at improvement rejected as "not in scope," "too late," or
> "no consensus," the IETF can now claim relevance and victory by
> conceding practically every principle ever held dear in return for
> the privilege of rubber-stamping Google's initiative.
>
> But the politics does not stop there.
>
> The reason HTTP/2.0 does not improve privacy is that the big corporate
> backers have built their business model on top of the lack of
> privacy. They are very upset about NSA spying on just about everybody
> in the entire world, but they do not want to do anything that
> prevents them from doing the same thing. The proponents of HTTP/2.0
> are also trying to use it as a lever for the "SSL anywhere" agenda,
> despite the fact that many HTTP applications have no need for, no
> desire for, or may even be legally banned from using encryption.
>
> Your Country, State, or County Emergency Webpage?
>
> Local governments have no desire to spend resources negotiating
> SSL/TLS with every single smartphone in their area when things
> explode, rivers flood, or people are poisoned. Big news sites
> similarly prioritize being able to deliver news over being able to
> hide the fact that they are delivering news, particularly when
> something big happens. (Has everybody in IETF forgotten CNN's
> exponential traffic graph from 14 years ago?)
>
> The so-called "multimedia business," which amounts to about 30% of
> all traffic on the net, expresses no desire to be forced to spend
> resources on pointless encryption. There are even people who are
> legally barred from having privacy of communication: children,
> prisoners, financial traders, CIA analysts and so on. Yet, despite
> this, HTTP/2.0 will be SSL/TLS only, in at least three out of four
> of the major browsers, in order to force a particular political
> agenda. The same browsers, ironically, treat self-signed certificates
> as if they were mortally dangerous, despite the fact that they offer
> secrecy at trivial cost. (Secrecy means that only you and the other
> party can decode what is being communicated. Privacy is secrecy
> with an identified or authenticated other party.)
>
> History has shown overwhelmingly that if you want to change the
> world for the better, you should deliver good tools for making it
> better, not policies for making it better.
>
> I recommend that anybody with a voice in this matter turn their
> thumbs down on the HTTP/2.0 draft standard: It is not a good protocol
> and it is not even good politics.
>
> Poul-Henning Kamp
>
> (Author of the Varnish HTTP web-accelerator.)
>
> PS: (Also published at: http://queue.acm.org/detail.cfm?id=2716278)
>
> --
> 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: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 07 Jan 2015 15:18:20 +0000

--------

Expectations Will Vary

The Answer is Politics

Poul-Henning Kamp

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 8 Jan 2015 11:50:11 +1000

On 8 January 2015 at 10:56, Greg Wilkins <[email-masked]> wrote
​ [heaps, which I will snip].

I agree pretty well with what Greg's written, and just want to add one
incidental outcome that may be considered a positive: by defining a
mechanism to allow HTTP/2 traffic to flow over the existing web, using
existing HTTP/1 ports (even if most browsers will only use HTTPS ports),
we've at least paved a way to allow other/future protocols to do the same.

I agree with James Snell's earlier sentiment as well, that HTTP/2 should
aim for Experimental, rather than Standards track. We've bought the upgrade
path (sorry, the ALPN-based TLS-as-an-opaque-tunnel path), so now we're
able to experiment with new/improved web protocols, and this is the first
such experiment.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 8 Jan 2015 01:56:56 +0100

The HTTP/2 proposal describes a protocol that has some significant benefits
over HTTP/1 and considering it's current deployment status, should be
progress to an RFC more or less as is.  However, the IESG should know that
it is a technical compromise that fails to meet some significant aspects of
it's charter.

I and others have discussed in the WG at length about what we see as
technical problems. These issues were given fair and repeated consideration
by the WG (albeit somewhat hurried on a schedule that was not really
apparent why it existed).   The resulting document does represent a very
rough consensus of the active participants, which is to the credit of the
chair who had to deal with a deeply divided WG.   But the IESG should note
that this also means that there are many parts of the protocol that are
border line "can't live with" for many participants.  It is not an exemplar
of technical excellence.

I believe that this is the result of a charter that sets up opposing goals
with little guidance on how to balance them.      Thus the core of my
feedback to this LC is not to iterate past technical discussions, but
rather to draw the IESG attention to the parts of the charter that are not
well met.

The httpbis charter for http2 begins be defining why HTTP/1 should be
replaced (my emphasis):

There is emerging implementation experience and interest in a protocol that
retains the semantics of HTTP without the legacy of HTTP/1.x message
framing and syntax, which have been identified as *hampering performance*
and
*encouraging misuse* of the underlying transport.
Some examples of the protocol misuse include:

   - breaking the 2 connection limit by clients in order to reduce request
   latency and to maximise throughput via the utilisation of multiple flow
   control windows.
   - use of long polling patterns to establish two way communication
   between client and server.
   - use of the upgrade mechanism to replace the HTTP semantic with
   websocket semantic has been described by some as a misappropriation of
   ports 80/443 for an alternative semantic.

I believe that the emphasis on performance (specifically browser "end-user
perceived latency", which is called out by the charter) has prevented the
draft from significantly addressing the misuse goal of the charter.   This
emphasis on efficiency over other design aspects was well characterised by
the editor's comment:

“*What we’ve actually done here is conflate some of the stream control
functions with the application semantics functions in the interests of
efficiency” *– Martin Thomson 8/May/2014
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0640.html>
This conflation of HTTP efficiency concerns into the multiplex framing
layer has caused the draft to fail to meet it's charter in several ways:

*Headers are not multiplexed nor flow controlled.*
Because the WG was chartered to "*Retain the semantics of HTTP/1.1,*" it
was the rough consensus that http/2 must support arbitrarily large
headers.  However, in the interests of supposed efficiency, HTTP header
semantics have been conflated with the framing layer and are treated
specially so that they are not flow controlled and they cannot be
interleaved by other multiplexed streams.

Unconstrained header size can thus result in head of line blocking (if for
example a large header hits TCP/IP flow control), which is a concern that
was explicitly called out by the charter.  Even without TCP/IP flow
control, small headers slowly sent, can hold out other messages from
initiating, progressing and/or completing.

While large headers are infrequently used today, the lack of flow control
and interleaving of headers represents a significant incentive for large
data to be moved from the body to the header.  History has shown that in
the pursuit of performances, protocols will be perverted!  So not only will
this likely increase the occurrence of head of line blocking, it is an
encouragement for to misuse the protocol, which breaks one of the two
primary goals of the charter.

*Websocket semantics are not supported.*
While the WG was chartered to "*coordinate this item with: ... * The HYBI
Working Group, regarding the possible future extension of HTTP/2.0 to carry
WebSockets semantics*", this has not been done to any workable resolution.
The conflation of the framing layer with HTTP means that it cannot operate
independently of HTTP semantics and there is now uncertainty as to how
websocket semantics can be carried over HTTP2.

An initial websocket proposal was based on using the existing DATA frames,
but segmentation features needed by websocket were removed as they were not
needed to support HTTP semantics.

Another websocket proposal is to define new frame types that can carry the
websocket semantic, however this suffers from the issue that intermediaries
may not understand these new frame types, so the websocket semantic will
not be able to penetrate the real world web.  Upgrading intermediaries is a
slow and difficult process that will never complete.

Yet another approach has been proposed and has been mentioned in this
thread as a feature. It is to use replace long polling with pushed streams.
A HTTP2 request/response stream is kept open without any data transfer so
that  PUSH_PROMISE frames can be used to initiate new streams to carry
websocket style messages server to client in pretend HTTP
request/responses.   This proposal has the benefit that by pretending to be
HTTP, websocket style semantic can penetrate a web that does not known
about the websocket semantic.  However, this is also the kind of protocol
abuse that the WG was chartered to avoid.

Instead of simply catering for the websocket semantic, the solution has
been to come up with an even more tricky and convoluted abuse of the HTTP
semantic for two way messaging.

*Priority is client side consideration only*
The entire frame priority mechanism is focused not only on HTTP semantics,
but on client side priorities.  The consideration has only been given to
what resources a client wishes to receive first and little if any
consideration has been given to the servers concerns for maximising
throughput and fairness for all clients.   The priority mechanism does not
have widely working code and is essentially a thought bubble waiting to see
if it will pop or float.

My own server (Jetty) currently plans to entirely ignore the priority
mechanism because it is expressed in a style and at a point that it is
entirely too late for the server to retrieve any substantial resources
already committed to a low client priority resource.  EG.  If the server
has launched an SQL query and is currently converting the data from a
cursor into HTML, it serves no purpose to subsequently tell it that the
client thinks it is a low priority data stream and would prefer other
resources first.  The server has committed thread, buffers, and scarce DB
connections to the request and it's priority is to complete the response
and recover those resources.

*In summary*
The draft as presented does represent a consensus of the WG, but also a
poor technical compromised between conflicting goals set by the charter.
While the performance goal appears to have been well met (at least for the
client side web traffic), the protocol does not remove incentives nor avoid
the need for protocol misuse, which ultimately may then end up compromising
the performance goals.   I would suggest that this is a result of
insufficient clarity in the charter rather than a poorly executed WG
process.

Further, I believe that by creating a proposal that is so specific to the
HTTP semantic we are missing an opportunity to create a multi semantic web,
where all traffic does not need to pretend to be HTTP and that new
semantics could be introduced without needing to redeploy or to trick the
web intermediaries and/or data centre infrastructure.

Unfortunately we are well along the path of deploying http2:  many if not
most browsers have support for it;  server implementations are available
and more are on their way;  several significant websites are already
running the protocol and reporting benefits;  intermediaries can mostly be
bypassed by the forced use of TLS (many say the misuse of TLS) and the
experts are exhausted from continual trench warfare on core technical
issues.

I don't think that http2 is a genie that can't easily be put back in the
bottle, nor can it be polished much more than it is, without a change of
charter.   Thus on balance I think it should probably be made an RFC.
Perhaps not in the standard track, but eitherway, we should do so knowing
that it has benefits, compromises, failures and missed opportunities.  We
need to work out how to do better next time.

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2015 00:14:18 +0100

Martin Thomson wrote:
> ...
> On 6 January 2015 at 05:13, Stefan Eissing <[email-masked]> wrote:
 > ...
>> 2. PUSH_PROMISE and header completeness
>> How are cache sensitive headers like "Authorization" handled in PUSH_PROMISE request headers? If simply left out, the client could store pushed resources in a cache where they do not belong. Should servers use extra Cache-Control directives in such pushed responses?
>
> This is part of the same sort of advice that your first question
> touches on: how do you effectively implement feature X.  Here, the
> rules are pretty easy to infer.  If you have a resource that would
> send Vary for a header field that the server cannot produce on its own
> then server push probably won't work.  Authorization is a great
> example.  The server might be able to produce *some* Authorization
> headers, particularly if one was in the request that the push is
> associated with though.
> ...

But then varying on "Authorization" does *not* require setting "Vary", 
because that aspect is baked into the protocol. (And some impls do the 
same thing for "Cookie" although not required by the spec).

Maybe this indicates that we just need more prose here.

>> Related: how is the role of the ACCEPT-* request headers? Should a client reject PUSH_PROMISE with request headers that does not match its own ACCEPT-* preferences? What if it uses ACCEPT-* and the PUSH_PROMISE is lacking those? Or the other way around?
>
> The same applies here.  A client uses the rules in Section 4 of RFC
> 7234 to determine whether a cached response can be used to satisfy its
> request.  If a client sends Accept: x/y and a server has pushed a
> response that included Vary: Accept and a content type that didn't
> match the clients preferred Accept header field, then the client
> should probably make a request rather than use the push.

This seems less of a problem than the one before as the HTTP responses 
are supposed to be self-descriptive, and clients *in general* an not 
assume that the server follows their preferences wrt Accept-*.

>> 3. Clarification on server-initiated push?
>> In discussions with colleagues some had the notion that HTTP2 would allow server initiated "requests". My reading of the draft is that this is not really the case. Server pushes are only defined for streams opened by the client.
>> - Is this the correct reading of the spec?
>> - If yes, has HTTP2 any advise how to best do long polling or what is the recommended alternative?
>
> Patrick has addressed that.  If you want a worked example of
> "long-polling" in HTTP/2, see
> https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html

Understood, but again it might be good if the spec actually was a bit 
clearer about this.

>> 4. SETTINGS_MAX_HEADER_LIST_SIZE as advisory
>> It seems undefined what a client (library) should do with it. Will this not give rise to interop problems if one client respects it and fails requests immediately while another does no checks and sends them anyway? MUST a peer that announces a limit always reply with 431 to requests that exceed it?
>
> Yes, this is a little nebulous, but intentionally.  If you consider an
> end-to-end protocol with multiple hops, the value that is actually
> enforced is the lowest value from all of the servers in the path of a
> request.  Since each request might follow different paths, the best
> that *this* protocol can do is provide information on the value
> enforced by the next hop (who knows if the next hop is even HTTP/2).
>
> The server is not required to send 431 if the size exceeds this: maybe
> some resources can handle streamed header fields, maybe some resources
> are forwarded to different origin servers.
>
> If you can't think of a concrete action to take based on this setting,
> I would ignore it.

Do we have any implementations that actually do something with this setting?

> ...
>> 7. Opinion: Chapter 9.1 Limitation to single connection
>> Have we not been here before? In the past, such SHOULD NOTs have not been very helpful. (Most likely already discussed heavily on the list...no strong feelings about this. It will be ignored anyway if not proving useful.)
>
> Indeed we have.  And when HTTP/1.1 advised a limit of 2 connections,
> that was done despite the fact that it was introducing a real
> limitation on the usability of the protocol.  2 wasn't a special
> number, it was just something someone made up (as is 6); 1 is one of
> the three important numbers, not an arbitrary choice.  Here, we have
> no such limitation because there is no corresponding limit on
> concurrency within the protocol.  There are still transport-level
> limitations (INIT_CWND, for instance), but I think some people expect
> to be lifting those over time.  I think that the working group is
> firmly intent in making this one stick.
> ...

Thread start: 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0147.html>

Ticket: <https://github.com/http2/http2-spec/issues/529>

I'm not very happy about the SHOULD, as we have heard about situations 
where it most definitively will be violated, see for instance William 
Chan in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0297.html>.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Sun, 11 Jan 2015 15:37:54 -0800

...
> Understood, but again it might be good if the spec actually was a bit

As always, pull requests are welcome.  I can't always take action
based on comments like these.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2015 07:24:57 +0100

> based on comments like these.

Understood.

Best regards, Julian

---

From: "Constantine A. Murenin" <[email-masked]>
Date: Sat, 10 Jan 2015 00:09:38 -0800

Dear IETF HTTP WG @w3.org,

I would like to express my disappointment with the HTTP/2 specification.

I believe that it fails to appropriately address RFC 7258 / BCP 188.

	http://tools.ietf.org/html/bcp188
	http://tools.ietf.org/html/rfc7258
	"Pervasive Monitoring Is an Attack"

Specifically, as a non-profit operator of multiple independent web-sites 
that do not warrant yearly acquisition and updates of CA-signed 
certificates, I am not pleased that HTTP/2 fails to include 
opportunistic encryption as part of the `http://` address scheme (and, 
according to http://queue.acm.org/detail.cfm?id=2716278, appears to even 
fail to require http:// address scheme support in the first place, 
effectively declaring all of us small independents as second-class 
citizens).

These are some of the specs for opportunistic encryption that should 
have possibly been made an integral part of HTTP/2 in compliance with 
BCP 188, but didn't:

	http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-unauth-enc-01
	"Minimal Unauthenticated Encryption (MUE) for HTTP/2"

	http://tools.ietf.org/html/draft-nottingham-http2-encryption-03
	"Opportunistic Encryption for HTTP URIs"

I have not deployed the https:// address scheme on any of my 
non-commercial web-sites, and do not plan on ever doing so, for the 
following major reasons:

0. The https:// address scheme is not backwards compatible with http or 
even with https itself:

0.0.  If someone clicks an https:// link, but their browser does not 
support https (maybe someone wants to visit my site from North Korea, or 
a WiFi sponsored by advertisements that only allows non-https 
connections, or a public office that administratively prohibits https 
connections), then they will be left disappointed.  They should instead 
be able to receive the non-encrypted version of the site, or an 
ad-filled copy of the web-site (my sites serve no ads), instead of being 
denied access outright.

0.1.  Similarly, the https:// address scheme is not even compatible with 
https itself.  Due to this incompatibility of https with https, as a 
web-site operator, one would be forced to either support broken and/or 
insecure SSL and TLS specs and/or ciphers that are not deemed BCP, and 
also engage in IPv4 address space waste for SNI-less clients, or to 
effectively engage in breaking and dividing the linked web again, since 
the https:// links wouldn't work in the slightly outdated browsers.

As a side note, I would also like to point out that even 
http://cr.yp.to/ is not available over https, and most likely never will 
be, most certainly due the compatibility issues as above.  Somewhat 
ironic, especially considering that the operator is also the author of 
ChaCha20 and Poly1305 ciphers used in TLS, and the domain name of the 
site is a domain hack of the word "crypto".

In the current situation, should any operator decide to enable 
"https://" address scheme with TLS 1.2 only, and only with 
ChaCha20-Poly1305 cipher suite, it is clear that many users will stop 
being able to access the site by following the linked web (and other 
users who are instead able to access such sites through https will 
undoubtedly start linking to such sites with the https:// address 
scheme), diminishing the linking potential of the world wide web as a 
whole.  In contrast, this wouldn't be the case should opportunistic 
encryption be deployed as part of the http:// address scheme instead.

1. Administrative costs for https:// address scheme are prohibitive:

1.0.  This concerns the initial certificate (and IPv4) acquisition. 
There are some efforts being made to simplify this process 
(LetsEncrypt), however, they are still not the reality.  I'm not even 
talking about SNI or lack thereof (Android 2.3 doesn't have SNI, for 
example, and it hasn't been that long since it stopped being shipped 
mainstream), so, in practice, this also involves IPv4 address space 
waste and the associated non-trivial monthly costs.

1.1.  The more important part is the continued maintenance.  The fact 
that it is considered a best practice for the certificates to be issued 
on a yearly basis conflicts with the idea of the set-it-and-forget-it 
mentality.  Let's face it, many useful web properties on the internet 
are left abandoned without updates for years, yet many of them remain of 
interest.
(Or do you suddenly think that http://ipv6samurais.com/ and 
http://www.itojun.org/ has no place to be?  Itojun, RIP.  Or would you 
enjoy a big warning on http://www.kohala.com/start/?  W. Richard 
Stevens, RIP.)
The https address scheme is not sustainable here, because it would start 
generating warnings about any such site (and that would even be the best 
case scenario, since 0.1 above might preclude any access to any such 
site in the first place, due to the failed TLS negotiation).

Additionally, some people just don't like using SSL, for whatever 
reason.  http://ftp.rodents-montreal.org/mouse/rodents-domain.txt 
HTTP/2 is not backwards compatible with such users, because the http:// 
address scheme is effectively being made obsolete by no longer being 
required to be implemented, without a good reason.

Why should users of older hardware supported by modern operating systems 
like NetBSD be precluded from having an option of having the encryption 
turned off?  This goes back to the legally-barred-from-having-privacy 
and the CO2 points raised by PHK over in another reply in this thread 
and at http://queue.acm.org/detail.cfm?id=2716278.

For the record:

a) I'm an operator of http://BXR.SU/ -- Super User's BSD Cross Reference 
-- a web-site containing 100k+ pages.  I am highly interested in 
deploying opportunistic encryption for the site.  As per above, 
deploying the https:// address scheme is completely out of the question 
for me, because it will result in denial of access to my site and broken 
links, and involve an unreasonable amount of extra administrative work 
in updating the certificates on a yearly basis, skyrocketing the 
maintenance time required.

b) I'm additionally the operator of http://mdoc.su/ -- short manual page 
URLs -- a service of semantic URLs for man.cgi of FreeBSD.org, 
OpenBSD.org, NetBSD.org and DragonFlyBSD.org, implemented through 
nginx.conf location and rewrite rules alone.  I believe there is no need 
for any kind of encryption scheme for such service, opportunistic or 
not.  I do not appreciate the sentiment of the HTTP/2 movement to 
effectively declare that my site is obsolete due to the lack of the 
https address scheme support.

I believe that the agenda of mandatory switching to https:// for 
everything conceivable, with loud warnings otherwise, goes in violation 
of the rights and interests of independents like myself who have neither 
the administrative nor the lobbying resources to follow or fight such 
change.

I am sincerely asking for the IETF to not approve HTTP/2 as a standard 
without the compatibility issues as above being addressed first.  The 
policy to abandon the http:// address scheme and adopt https:// will 
only promote a significant link rot for the future generations to 
experience well into the future (didn't we think TLS 1.0 was good 
enough?), and will curtail independent and hobbyist operators.

Best regards,
Constantine A. Murenin,
MMath CS, UWaterloo '10.

---

From: "Constantine A. Murenin" <[email-masked]>
Date: Mon, 12 Jan 2015 17:35:08 -0800

On 2015-01-12 16:30, Willy Tarreau wrote:
> Hello,
>
> On Sat, Jan 10, 2015 at 12:09:38AM -0800, Constantine A. Murenin wrote:
> Please note that the protocol *does* support http:// address scheme, it's
> only that two browsers decided that they will not implement it. Let's hope
> that they'll change their mind when HTTP/2 starts reaching normal users and
> is no more limited to huge sites with lots of people to manage certificates.

Has this been changed since the publication of 
http://queue.acm.org/detail.cfm?id=2716278, which claims that it's 3 out 
of 4 major browsers that will only do HTTP/2.0 with TLS?

PHK>>>> Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at least 
three out of four of the major browsers, in order to force a particular 
political agenda. The same browsers, ironically, treat self-signed 
certificates as if they were mortally dangerous, despite the fact that 
they offer secrecy at trivial cost.

Regardless, this doesn't change the fact that HTTP/2, as proposed, lacks 
soft upgrade/downgrade provisions -- from the server side, you either 
have to carry the whole pre-HTTP/2 SSL/TLS baggage, pre-TLSv1.2 and all, 
or not deploy HTTP/2 at all; else, some of your customers won't be able 
to access the site at all, after they get the https:// links from 
customers that do.

This wouldn't have been the case with opportunistic encryption.  It 
would have ensured full protection against passive monitoring attacks, 
in compliance with Best Current Practice 188.  HTTP/2 does nothing to 
combat the widespread passive monitoring.

Cheers,
Constantine.

---

From: Cory Benfield <[email-masked]>
Date: Tue, 13 Jan 2015 09:44:39 +0000

On 10 January 2015 at 08:09, Constantine A. Murenin <[email-masked]> wrote:
> without the compatibility issues as above being addressed first.  The policy
> to abandon the http:// address scheme and adopt https:// will only promote a
> significant link rot for the future generations to experience well into the
> future (didn't we think TLS 1.0 was good enough?), and will curtail
> independent and hobbyist operators.

For the sake of clarity: no such policy exists in the specification as
drafted by this working group. The policy comes from specific
implementers, most notably Chrome and Firefox, as discussed by Amos
and Willy. I recommend taking your complaint up with those
implementers through their recommended feature request/bug reporting
channels.

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 13 Jan 2015 10:58:23 +0100 (CET)

On Mon, 12 Jan 2015, Constantine A. Murenin wrote:

>> Please note that the protocol *does* support http:// address scheme

> http://queue.acm.org/detail.cfm?id=2716278, which claims that it's 3 out of 
> 4 major browsers that will only do HTTP/2.0 with TLS?

1. That's an article on an unrelated site, not a product from the IETF. Basing 
HTTP/2 spec commentary on that seems like the wrong approach. Read the spec 
and base your critiques on that please.

2. On this list we have seen spokespeople from two browsers state this intent 
of implementing TLS-only. I personally am interested to learn which that third 
browser is since I wasn't aware of anyone publicly speaking for Safari's 
stance on this?

-- 

  / daniel.haxx.se

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 13 Jan 2015 17:14:32 +1300

On 13/01/2015 2:35 p.m., Constantine A. Murenin wrote:
>>> I am sincerely asking for the IETF to not approve HTTP/2 as a
>>> standard without the compatibility issues as above being
>>> addressed first.  The policy to abandon the http:// address
>>> scheme and adopt https:// will only promote a significant link
>>> rot for the future generations to experience well into the
>>> future (didn't we think TLS 1.0 was good enough?), and will
>>> curtail independent and hobbyist operators.
>> 
>> Please note that the protocol *does* support http:// address
>> scheme, it's only that two browsers decided that they will not
>> implement it. Let's hope that they'll change their mind when
>> HTTP/2 starts reaching normal users and is no more limited to
>> huge sites with lots of people to manage certificates.
> 
> http://queue.acm.org/detail.cfm?id=2716278, which claims that it's
> 3 out of 4 major browsers that will only do HTTP/2.0 with TLS?

Nothing has changed. You just seem to be slightly misunderstanding the
situation.

The protocol spec defines both http:// and https:// on equal footing
for HTTP/2 just as they were for HTTP/1. As Willy mentioned.

Those browsers have chosen (for now) to ignore whole sections of the
specification and the WG chartered requirements that HTTP/2 to be
usable in *all* use-cases where 1.1 was. By vehemently not
implementing that support and forcing their users through all those
problems you describe (I pity their users but karma will have its way).

PHK, and others including myself, are at the other extreme of the
spectrum not implementing https://. Though we have not been refusing
to ever do so (that just seems a stupid claim to make).

It is a reflection on some implementers arbitrary choice to ignore the
specification text (er, "forever"). Not an explicit lacking in the
specification itself. It makes little sense for a protocol to say
"MUST implement this specification". But it does make for an
interesting birth to the new protocol.

> 
> PHK>>>> Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at
> least three out of four of the major browsers, in order to force a
> particular political agenda. The same browsers, ironically, treat
> self-signed certificates as if they were mortally dangerous,
> despite the fact that they offer secrecy at trivial cost.
> 
> Regardless, this doesn't change the fact that HTTP/2, as proposed,
> lacks soft upgrade/downgrade provisions -- from the server side,
> you either have to carry the whole pre-HTTP/2 SSL/TLS baggage,
> pre-TLSv1.2 and all, or not deploy HTTP/2 at all; else, some of
> your customers won't be able to access the site at all, after they
> get the https:// links from customers that do.
> 
> This wouldn't have been the case with opportunistic encryption.
> It would have ensured full protection against passive monitoring
> attacks, in compliance with Best Current Practice 188.  HTTP/2 does
> nothing to combat the widespread passive monitoring.

This is incorrect.

Soft upgrade/downgrade in https:// is done with ALPN and the reason
why that TLS feature is now mandatory for https://.

Soft upgrade in http:// is done via HTTP Upgrade mechanism same as
with HTTP/1. The sad reality that it lacks widespread HTTP/1.1
implementation support to actually perform the switch does not detract
from its existence as a feature in the protocol and potential use when
opportunity presents it. Its active use by HTTP/2 implementations to
transition should also improve the environment/availability for
opportunistic upgrades.

The TLS/SSL baggage needing to be implemented is no different for
HTTP/2 as for HTTP/1.x. The expectation is that the baggage
requirements become smaller over time. After the events of the past
few months in particular all the SSL baggage should not be an issue
for any HTTP/2 implementation and the TLS built-in upgrade mechanism
is actively minimizing the remaining legacy issues.

The HTTP/2 does change the BCP 188 state over HTTP/1.1:
 * explicitly forbids use of the crypto schemes currently known to be
(or expected soon to be) vulnerable to monitoring.
 * multiplex+compressed traffic raising the difficulty bar to passive
monitoring identifying any given client from packet statistics through
intermediaries.
 * provides extensibility points for future strong cryptography even
in the "clear-text" HTTP/2 connections.
 * provision to opportunistically remove (or compress away) features
of HTTP/1 used as client identification/signature footprints by monitors.
 * lack of opportunistic downgrade for http:// raises the difficulty
bar for active attackers to impose a weak HTTP/1.x environment on
clients initiating native HTTP/2.

It also does a few things which lower the bar in some ways if
implemented (TLS ALPN, and the native magic prefix can still be hijacked).
So your assertion that it "does nothing" is incorrect. It does what
can be done in HTTP at this point in time. True it is just a small
improvement, but non-zero.

Amos Jeffries
Squid Software Foundation

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 13 Jan 2015 01:30:55 +0100

Hello,

To their defense, the last reported connection upgrade success rates were
rather low (80-90% or something like this) and it can take a few years for
broken intercepting proxies to be upgraded/fixed at ISPs. I don't remember
when that measure was done, I guess it was 3 years ago for WebSocket. But
I do still hope we'll see support for http:// over HTTP/2 in all browsers
when HTTP/2 becomes the most commonly deployed version.

Best regards,
Willy