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

[Eric Rescorla <[e-mail]>]

Brian,

Thanks for taking the time to send your extensive message about ALPN vs. NPN.

After reviewing your request, the chairs believe that it does not raise any
new substantive issues that were not known to the WG at the time of the
decision to adopt ALPN and the subsequent WGLC. Therefore, we do not
believe it is appropriate to re-open the issue at this time.

Because the document has already passed WGLC, we will be asking the
AD for advancement. You should of course feel free to reraise your objections
during IETF LC.

-Ekr

[For the chairs]



On Mon, Dec 9, 2013 at 11:22 PM, Brian Smith <[e-mail]> wrote:
> 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
>
> [