Subject: Please don't block HTTP/2 on the "http:// schemed URIs over TLS" issue

From: Brian Smith <[email-masked]>
Date: Tue, 4 Mar 2014 22:35:00 -0800

In the Zurich interim meeting of the HTTP/2 working group in January, there
was strong agreement amongst the people in the room that it is critical
that we quickly resolve the remaining blocking issues so that HTTP/2 can
advance through the standards process, in order to encourage the quick
deployment of HTTP/2 by web browsers and by websites. The improved
efficiency of HTTP/2 will foster more widespread adoption of HTTPS by
addressing some of the biggest performance concerns (valid or otherwise)
that website administrators have with TLS. The sooner we finish the HTTP/2
spec, the sooner these benefits will be realized.

One of the biggest areas of contention at that meeting was the
"http://schemed URIs over TLS" issue. It was clear in the Zurich
meeting that we
were nowhere close to having consensus on that feature. However, we
ultimately decided to give the proponents of the feature more time to try
improve their proposal [1]: "Discussed in Zurich; further discussion in
London; mark and patrick to revise draft and experiment. However, this will
not block HTTP/2 unless delay is minimal."

My main request here is that we stick to that agreement to not delay HTTP/2
further.

What is in the current HTTP/2 draft is mostly well-tested and widely agreed
upon. The proposed unauthenticated TLS feature has not been widely tested
and there is still a lot of disagreement on it, especially across browser
makers. As far as I can tell, it simply isn't ready for the standards
track, as it is clearly still too experimental. Note that I'm not using
"experimental" in any derogatory sense; experimentation is a good thing,
and I think it is worth continuing to experiment with all kinds of
potential solutions for improving security and privacy on the internet.

I remain unconvinced about the net value of unauthenticated encryption. A
big unanswered question is whether, and how much, adding the option of
unauthenticated encryption would hurt the adoption of fully-authenticated
HTTPS. I've seen no convincing evidence for or against that. Fundamentally,
the reason it is hard to tell if it would be a net gain or a net loss is
because the problems we are trying to solve are social problems that
protocol specifications will not resolve.

I think that the meaningfulness of the distinction between passive
surveillance and surveillance that uses active man-in-the-middle attacks
has been vastly oversold. mitmproxy and Firesheep already exist. The idea
that we are going to defeat national spying agencies using technology that
my little brother can bypass with off-the-shelf tools is hard for me to
take seriously without better evidence to support it. I understand that the
argument is that the spying organizations will not want to get caught
red-handed, and that they are more likely to get caught if they perform
active attacks than passive attacks. However, in the Zurich meeting,
multiple ISP-type representatives said that their organizations would
*definitely* perform active man-in-the-middle attacks on unauthenticated
TLS so they could do caching and other things. Also, the "Explicit Trusted
Proxy in HTTP/2.0" draft shows that the vendors of proxy products consider
unauthenticated TLS to be a *facilitator* for the inspection and
modification of traffic that passes through their products, and that the
performance cost of performing the active attacks is marginal. If active
man-in-the-middle interception of unauthenticated TLS would really be so
widespread, then it is seems completely impractical to layer any kind of
usable novel authentication scheme or surveillance detection mechanisms on
top of it, because there would be too many false-positives for users to
deal with. And, once ISPs have unwrapped your traffic, the spying agencies
can access it undetected using the same or similar mechanisms they are
reportedly currently using.

At this time, I still believe that the best thing we could do (the IETF,
and more specifically web browsers, and even more specifically Mozilla) to
advance web transport security is to deploy HTTP/2.0 over TLS exclusively.
I very much support the idea that Jeff Pinner proposed in Zurich of moving
the UPGRADE-based negotiation mechanism out of the base specification. Then
the IETF would be making a strong statement that non-secure HTTP is
deprecated. I believe that this would force us to finally confront the hard
problems that the unauthenticated TLS proposal is trying to route around.
We should tackle those problems head on.

I know that some people have taken my previous statements of this argument
as proposing to "do nothing." Just to be 100% clear, I strongly agree that
we have a lot of work to do to improve security and privacy on the
internet. My point is that we don't need to do add those things to the
HTTP/2 specification. A lot of that activity actually belongs in other
working groups and even in other organizations outside of IETF.

Even if you disagree with my questioning of the value of unauthenticated
encryption, I hope that you can at least see that the most important thing
that the HTTP working group can do now is to ensure that the HTTP/2
specification gets finished so that we all can deploy it. Let's avoid any
more delays.

Thanks for reading all the way through this! I appreciate your
consideration.

[1] https://github.com/http2/http2-spec/issues/315

Cheers,
Brian Smith
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Mar 2014 09:12:05 +0100

On 2014-03-05 07:35, Brian Smith wrote:
> In the Zurich interim meeting of the HTTP/2 working group in January,
> there was strong agreement amongst the people in the room that it is
> critical that we quickly resolve the remaining blocking issues so that
> HTTP/2 can advance through the standards process, in order to encourage
> the quick deployment of HTTP/2 by web browsers and by websites. The
> improved efficiency of HTTP/2 will foster more widespread adoption of
> HTTPS by addressing some of the biggest performance concerns (valid or
> otherwise) that website administrators have with TLS. The sooner we
> finish the HTTP/2 spec, the sooner these benefits will be realized.
> ...

The charter says we're doing a protocol that can replace HTTP/1.1:

"Retain the semantics of HTTP/1.1, leveraging existing documentation 
(see above), including (but not limited to) HTTP methods, status codes, 
URIs, and where appropriate, header fields."

If it can't do HTTP URIs, it's not a replacement. What we need to argue 
about is not *whether* to support HTTP URIs, but *how*.

If you believe it's ok to abandon HTTP URIs then you should lobby for a 
rechartering of the WG.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 5 Mar 2014 09:59:05 +0100

Le Mer 5 mars 2014 07:35, Brian Smith a écrit :

Hi,

> My main request here is that we stick to that agreement to not delay
> HTTP/2 further.

I believe proxy interaction in an integral part of the http spec (both 1
and 2) and it would be a mistake to push http2 before resolving the few
issues around proxy use.

We've read a lot of "won't do" statements by browser representatives
around proxy use on this list in the past months, but little light on what
they will actually do. This part of the spec is clearly incomplete today
and no one can tell if finishing it will require adjustments in the rest
of the spec or not.

(grandfathering http1 proxy elements in http2 when everyone seems to agree
they are badly written and only generate problems browser, web site and
proxy side strikes me as woefully bad idea. http1 proxy auth does not work
by design with tls sites today and http2 is used by browsers
representatives to generalise tls, how can this ever result in a good user
experience?)

Regards,

-- 
Nicolas Mailhot

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 09:08:30 +0000

On 5 March 2014 08:59, Nicolas Mailhot <[email-masked]> wrote:
> This part of the spec is clearly incomplete today

This is a known issue (see
https://github.com/http2/http2-spec/issues/413). If you would like to
see this issue resolved, perhaps I could ask you to make a more
concrete recommendation for how to improve the specification.  There's
been a lot of discussion on the topic, but I'm having difficulty
identifying any actionable outcomes.

---

From: James Cloos <[email-masked]>
Date: Fri, 07 Mar 2014 18:38:40 -0500

>>>>> "JR" == Julian Reschke <[email-masked]> writes:

JR> If it can't do HTTP URIs, it's not a replacement. What we need to
JR> argue about is not *whether* to support HTTP URIs, but *how*.

The draft specifies http upgrade to support http/2 for http:// URIs.

TLS has nothing to do with that issue.  (Nor should it.)

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Appanasamy, Palanivelan" <[email-masked]>
Date: Mon, 10 Mar 2014 09:17:25 +0530

This is little more complicated than what it looks to be :)
Let us get 2.0 rolled out  and Focus on all "MUST" adds for the immediate future.

Regards,
Palanivelan
-----Original Message-----
From: James Cloos [mailto:[email-masked]] 
Sent: Saturday, March 08, 2014 5:09 AM
To: [email-masked]
Cc: Julian Reschke; Brian Smith
Subject: Re: Please don't block HTTP/2 on the "http:// schemed URIs over TLS" issue

-JimC