[TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)

[Brian Smith <[e-mail]>]

Hi all,

My name is Brian Smith and I am the lead on Mozilla Corporation's work
on TLS, PKI, and some related things (though *not* DTLS or other
WebRTC networking stuff, which EKR does a fine job of leading). I am
primarily responsible for working to secure Firefox, but most of my
work also applies to Thunderbird and other software based on our
"Gecko" engine. Note also that Mozilla has implemented APIs to allow
certain kinds of HTML5 applications to make TCP connections in a way
that enables them to implement any TCP protocol (SMTP, IMAP, etc.),
not just HTTP, SPDY, and WebSockets. Therefore, our interest in
protocol negotiation goes much further than negotiating just HTTP/1
vs. HTTP/2, though that is by far the most important use case for us.

For the reasons I note below, I think we should re-evaluate whether we
still have consensus on moving forward with recommending ALPN as the
protocol negotiation mechanism to be used in TLS and specifically in
HTTP/2. I would like the working group to re-consider the option of
recommending the more secure and more private NPN mechanism instead,
at least until TLS 1.3 can offer an even better alternative mechanism.

In IETF86, there was some kind of vote in favor of ALPN over NPN. I
could not attend that IETF for personal reasons, so I don't know the
nature of the vote or how binding it is and whatnot. Also, I know ALPN
has gone through WGLC already. I regret that I chose to voice my
opposition to ALPN only privately to EKR before IETF86 and during
WGLC. That was definitely a mistake on my part, and I'm truly sorry
for making it.

Since IETF86, and since WGLC, there have been new developments. I
tried to go into detail on many of them in the "ALPN concerns" thread,
but here is a summary:

* During the summer, the Edward Snowden stuff happened, making us
(more) aware of widespread, worldwide, spying on the users of our
software. If nothing else, I hope we have learned from Snowden's work
that we need to be particularly careful to maximize privacy from
network attackers in the protocols and software we create.

* Stephen Farrell published the first draft of "Pervasive Monitoring
is an Attack" [0], which states (in part; please read the whole
thiing):

   The technical plenary of IETF 88 [IETF88Plenary]
   discussed pervasive monitoring and participants
   had strong agreement that this was an attack and
   one that should be mitigated where possible via
   the design of protocols that make pervasive
   monitoring significantly more expensive or
   infeasible.
   ...

   For the purposes of this BCP "pervasive monitoring"
   means very widespread privacy-invasive gathering of
   protocol artefacts including application content,
   protocol meta-data (such as headers) or keys
   used to secure protocols.
   ...
   This BCP simply records the consensus to design
   protocols so as to mitigate the attack, where possible.

Note that the protocol/options metadata that would be negotiated in
ALPN or NPN or whatever is protocol metadata. I think there is no
disputing that NPN (or a new design that works more like NPN) helps
make attacks more expensive, even though it may not make any attack
impossible, and that switching from NPN to ALPN would only help
facilitate attacks.

* Joseph Salowey wrote the first draft of a proposed new charter for
the TLS Working Group [1]. That draft says, in part:

    o Develop a mode that encrypts as much of
      the handshake as is possible to reduce
      the amount of observable data to both
      passive and active attackers.

Thus, standardizing unencrypted ALPN now seems likely to be in direct
contradiction to our future charter.

* During IETF88, EKR published the TLS 1.3 flows draft [2]. This draft
is extremely helpful for seeing that TLS 1.3 is likely to be quite
complex, even before we try to encrypt the ALPN and/or SNI extensions
in the ClientHello. Also, it does not show a viable means of
encrypting the ALPN extension in a backward-compatible (with
unencrypted ALPN) way. (A mechanism for encrypting ALPN would have to
do so without adding any round trips to be viable.) Thus, the idea
that we can standardize unencrypted ALPN now, and then somehow fix it
in TLS 1.3, seems extremely unrealistic.

* During IETF87, Microsoft suggested that we need to extend protocol
negotiation to support the negotiation of options. My understanding is
that we should expect the HTTP WG to specify some such options in
HTTP. AFAICT, the need for ALPN or NPN to support an open-ended set of
negotiated information in addition to the protocol was not considered
when considering the security of ALPN.

* Mark Nottingham wrote his Opportunistic Encryption for HTTP URIs
draft [3], which is a specific example of option negotiation described
in the previous point. Mark also wrote [4] that he is concerned that
the HTTP 2.0 work may not be able to go forward without a viable means
of doing opportunistic encryption.

* I described [5] (I recommend reading the whole thread, despite how
many words there are in it) several technical objections to switching
to ALPN from NPN on privacy and security groups, and noted that NPN is
still much more widely deployed and generally meets our goals better.

* I also described [6] how choosing ALPN over NPN would weaken the
security properties of Mark's Opportunistic Encryption for HTTP draft.
It is hard to see how it would be reasonable to do opportunistic
encryption using Mark's proposed mechanism on top of ALPN, considering
the significant weakness ALPN adds to it, that NPN doesn't.

* In [6], I also showed that it isn't necessarily true that traffic
analysis can yield information equivalent to ALPN, which was a key
argument in favor of ALPN. Note that this is just the simplest
possible example. I think we can be much more successful against
traffic analysis in general, by adding features to TLS that make
traffic analysis difficult, such as [7], and I actually don't
understand why we gives any credence to the "traffic analysis makes
the argument moot" argument; that seems very defeatist to me. Perfect
traffic analysis prevention may be impractically expensive, but it is
far from clear that imperfect traffic analysis is worthless. Tor is a
pretty good but imperfect mechanism for preventing traffic analysis,
and it seems to work surprisingly well.

* I described [8] a potential solution for moving the
application-level protocol negotiation out of the TLS protocol in "TLS
1.3" without hurting performance, at least in common cases.

I don't have any political position in the argument of ALPN vs. NPN
vs. whatever. My concerns are purely technical and purely based on my
desire to maximize privacy and security for the users of my software
and even my competitors' software. It is clear to me that ALPN is
strictly worse than NPN in terms of protecting privacy and security of
users. (FWIW, it would literally be easier for me to add ALPN support
to Firefox than it would be for me to have typed up all these messages
to the working group mailing list.)

We can argue about whether ALPN is "good enough" (and I've argued
extensively it isn't) but I fail to see why we should settle for
something worse at all, especially when the choice of NPN better suits
the motto of the IETF, "rough consensus and running code," as
demonstrated by the large number of *deployed-in-production* NPN
implementations. (If you used a web browser today, you probably used
NPN). Therefore, I strongly encourage people to choose NPN instead of
ALPN, which is my strong preference for Firefox, Thunderbird, and
other Mozilla products. And, I would be very happy to do all the
editing work on the NPN draft to get it into shape for being a
proposed standard.

Cheers,
Brian

[0] http://tools.ietf.org/html/draft-farrell-perpass-attack-00
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10759.html
[2] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00
[3] http://tools.ietf.org/html/draft-nottingham-http2-encryption-01
[4] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html
[5] http://www.ietf.org/mail-archive/web/tls/current/msg10405.html
[6] http://www.ietf.org/mail-archive/web/tls/current/msg10890.html
[7] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00
[8] http://www.ietf.org/mail-archive/web/tls/current/msg10888.html

[