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

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)