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

From: Brian Smith <[email-masked]>
Date: Mon, 9 Dec 2013 07:22:48 -0800

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

[

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Dec 2013 20:46:44 +0000

On 12/09/2013 03:22 PM, Brian Smith wrote:
> I think we should re-evaluate whether we
> HTTP/2.

+1

I was in the room and I recall the discussions. I went to the microphone
and expressed my excitement about the fact that privacy related topics
where discussed in the TLS working group (given that privacy wasn't an
issue previously) and the response was "This has nothing to do with
privacy.".

Luckily we know much better now (or at least some people do).

Ciao
Hannes

---

From: Tom Ritter <[email-masked]>
Date: Tue, 10 Dec 2013 16:40:26 -0500

+1

I raised my preference for NPN over ALPN (and for generic post-CCS
extensions) last time around on the mailing list, and still keep that
preference.

-tom

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 22:19:10 +0000

> Luckily we know much better now (or at least some people do).

(no hats as usual)

FWIW, I agree with you in general, but in this case the privacy
leak is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since
the binary encoding and lack of head-of-line blocking in the
latter will give that game away anyway.

I'd say focusing on tls1.3 and any privacy gains there is better
than diverting effort to NPN to be honest.

S.

> 
> Ciao
> Hannes
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Dec 2013 14:30:53 +0800

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]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 10 Dec 2013 18:44:22 -0500

> latter will give that game away anyway.

i don't think i understand this argument.  are you saying that traffic
analysis will disclose what protocol is in use in this case?

if so, that's still a win; we've forced a passive attacker to move from
trivial byte-string matching to traffic analysis, which is more complex
and less certain.  And we can further complicate traffic analysis with
other approaches like Pironti's length hiding:

  http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00

And protocol negotiation is not only useful in the HTTP/1.1→HTTP/2.0 use
case.

> than diverting effort to NPN to be honest.

The concern raised by Brian Smith is that if TLS 1.3 is an upgrade to
TLS 1.2 with cleartext ALPN, based on how we understand negotiated TLS
today, then compliant clients may have a strong incentive to continue to
send cleartext ALPN, so that they can negotiate with servers not yet
capable of TLS 1.3.

If we settle on ALPN now, the information in ALPN seems likely to remain
in the clear for lots of handshakes even after TLS 1.3 is widely
deployed.  If one of the goals of TLS 1.3 is encrypting as much of the
handshake as possible (which i think it should be), then standardizing
ALPN now seems to work against the goals of TLS 1.3 more strongly than
any diversion of effort related to NPN.

        --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 15:04:32 +0000

On 12/10/2013 11:44 PM, Daniel Kahn Gillmor wrote:
>> leak is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since the
>> binary encoding and lack of head-of-line blocking in the latter
>> will give that game away anyway.
> 
> i don't think i understand this argument.  are you saying that
> traffic analysis will disclose what protocol is in use in this
> case?

I believe so, esp since there's just http/1.1 and http/2.0 in
question (well, maybe spdy too for some time). If hiding that
somewhat is the claimed benefit and if that diverted scarce
WG resources away from tls1.3 then I figure doing the work
in tls1.3 is better.

> if so, that's still a win; we've forced a passive attacker to move
> from trivial byte-string matching to traffic analysis, which is
> more complex and less certain.

If we're only dealing with the above protocols, then I don't
think it'd be at all hard to distinguish 'em.

> And we can further complicate traffic analysis with other
> approaches like Pironti's length hiding:
> 

I really like the idea of meeting that requirement. But again
it seems to me like it'd be better baked into tls1.3 and not
done as an extension to tls1.2 or earlier. My reasoning there
assumes that we figure tls1.3 will be widely deployed more
quickly than previous updates due to the collective win of
running http/2.0 over tls1.3. Doing a lot of things in both
tls1.3 and as extensions to earlier versions also seems less
likely to work out, given that we all have limited cycles.

But yes, that's prediction with which one could disagree.

> And protocol negotiation is not only useful in the
> HTTP/1.1?HTTP/2.0 use case.
> 
> The concern raised by Brian Smith is that if TLS 1.3 is an upgrade
> to TLS 1.2 with cleartext ALPN, based on how we understand
> negotiated TLS today, then compliant clients may have a strong
> incentive to continue to send cleartext ALPN, so that they can
> negotiate with servers not yet capable of TLS 1.3.

Yep, that is a good question to consider. I don't think I've seen
it addressed either, but maybe I missed that.

> If we settle on ALPN now, the information in ALPN seems likely to
> remain in the clear for lots of handshakes even after TLS 1.3 is
> widely deployed.  If one of the goals of TLS 1.3 is encrypting as
> much of the handshake as possible (which i think it should be),
> then standardizing ALPN now seems to work against the goals of TLS
> 1.3 more strongly than any diversion of effort related to NPN.

Depends on what ALPN values would be present in a case where tls1.3
and http/2.0 are supported. I don't know what'd be likely there.

S.

> 
> --dkg
> 
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Dec 2013 15:16:29 +0000

I think it's possible to get all the extension hiding we want in TLS 1.3, even while keeping BC with TLS 1.0 servers:

1. Client sends ClientHello without the problem extensions (ALPN, SNI). The record version is 3.1 (TLS 1.0), while the supported version is 3.4 (TLS 1.3). 

2a. The server replies with TLS 1.3, and everything works as planned. The end.

2b. The server replies with TLS 1.0, and some certificate. The certificate may or may not fit the site. Makes no difference for now.
3b. The client completes the exchange, and immediately begins a renegotiation
4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS 1.2, and all extensions are present (though encrypted).
5b. The renegotiation completes at TLS 1.0 with all extensions.

This solves the issue of hiding extension. If TLS 1.3 is not supported by the server, it means an extra handshake with all associated costs. It may be possible, if the server presented the correct certificate to have session resumption with the renegotiation, although that is usually not recommended.

Yoav

---

From: Bill Frantz <[email-masked]>
Date: Wed, 11 Dec 2013 11:14:17 -0800

From the desires people are putting into tls 1.3 perhaps we are 
actually talking about tls 2.0.

We should not insist that a client using the new protocol be 
able to connect of a tls 1.2 server (or below) as a result of 
tls level negotiation. The fallback mechanisms in most browsers 
can cover that need. The extra design freedom will allow us to 
easily encrypt data that was previously sent in the clear 
without worrying about backward compatibility.

We may find the resulting simplicity a clear win.

I would be delighted to be wrong and see a simple tls 1.3 negotiation.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Dec 2013 16:50:29 -0500

> 5b. The renegotiation completes at TLS 1.0 with all extensions.

This approach should work to hide all extensions in current versions of
TLS as well, right?  But no one does it, as far as i know.

Do you know of any TLS client library which does this, or provides an
option to do it without a bunch of manual intervention in the workflow
of the TLS stack by the library user?  Do you think certain tools or
users should be doing this now?

Are there any extensions which require that their content must be
identical across session resumption or across a re-handshake?

If so, it doesn't seem like those extensions could be used in this
re-handshake approach.

	--dkg

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Dec 2013 22:17:20 +0000

> TLS as well, right?  But no one does it, as far as i know.

Not that I'm aware of either, but it's not that different from hiding client certificates by making the first handshake server-authenticated, and the second handshake mutually-authenticated. That is something that some servers do, and all the clients cooperate nicely.

> users should be doing this now?

I've seen the client certificate hiding done with Apache and OpenSSL. I don't think any information in the TLS handshake is as sensitive as the user name in the certificate.

> identical across session resumption or across a re-handshake?

Not to my knowledge.

---

From: Brian Smith <[email-masked]>
Date: Wed, 11 Dec 2013 15:53:47 -0800

> This solves the issue of hiding extension. If TLS 1.3 is not supported by the server, it means an extra handshake with all associated costs. It may be possible, if the server presented the correct…

Thanks for trying to find a solution. However, it is not acceptable to
add any new round trips to hide information in the ClientHello, and
also we can't add whatever compatibility risk there would be in
depending on renegotiation (the compatibility issues with even initial
handshakes are a huge drain). If/when we have ~99% adoption of TLS 1.3
with encrypted ClientHello information, we could revisit this kind of
approach. But, that is several (10?) years away. Until then, we'd need
an approach that doesn't add any round trips to the handshake.

Keep in mind that if it were acceptable to add new round trips to the
handshake, we wouldn't need ALPN or NPN at all.

In fact, we don't need ALPN or NPN for the case of a 1-RTT handshake,
if we standardize a way to allow protocol-neutral prefixes of the
application data, like I showed at the end of this message:
http://www.ietf.org/mail-archive/web/tls/current/msg10888.html

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

---

From: Brian Smith <[email-masked]>
Date: Wed, 11 Dec 2013 15:59:46 -0800

On Wed, Dec 11, 2013 at 11:14 AM, Bill Frantz <[email-masked]> wrote:
> We should not insist that a client using the new protocol be able to connect
> of a tls 1.2 server (or below) as a result of tls level negotiation. The
> fallback mechanisms in most browsers can cover that need. The extra design
> freedom will allow us to easily encrypt data that was previously sent in the
> clear without worrying about backward compatibility.

I think us browser people might have unintentionally misled people
about our eagerness to reconnect with downgraded security properties.
I, and other browser people I know, consider it mis-feature, and we'd
love to find a way to stop doing it. So, trying to connect via "TLS
2.0" that has better security/privacy properties, and then insecurely
falling back to TLS 1.2 with worse security/privacy properties, is
something that I'd definitely want to avoid.

There may be cases where the
connect-and-then-reconnect-with-different-parameters approach becomes
useful, but the key there is "different" and not "worse."

Besides being an ineffective security/privacy measure (since any MitM
could induce the fallback to from "TLS 2.0" to TLS 1.2), it would also
be unacceptable due to the added latency for any site that hadn't
upgraded to "TLS 2.0." We are many years away from that becoming a
viable thing for us to do.

Cheers,
Brian

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Dec 2013 16:01:58 -0800

Can someone explain to me why "fuck you, make the protocol backwards
compatible" is not an acceptable response to those asking for
these things? The client has a perfectly fine way to send information
to the server, namely via the channel TLS establishes. Judging from
this and other threads, people want to make us do work that they can
do over the encrypted channel instead leading to all sorts of debates
over
what semantics are appropriate, and making it even hard to design a
next generation protocol to fix known problems.
Sincerely,
Watson Ladd

---

From: Brian Smith <[email-masked]>
Date: Wed, 11 Dec 2013 16:44:18 -0800

On Wed, Dec 11, 2013 at 7:04 AM, Stephen Farrell
<[email-masked]> wrote:
> question (well, maybe spdy too for some time).

Hi Stephen,

You made this argument in two different threads, and I'll just reply
in this one.

I am not concerned about a MitM learning whether you are talking
HTTP/1 vs HTTP/2 vs. SPDY. If ALPN were only capable of disclosing
which version of HTTP you are speaking, I'd not be objecting so
strongly to it.

However, the ALPN draft [0] isn't HTTP-specific. It happens to be the
case that only HTTP-related protocol identifiers are currently planned
to be registered, but that doesn't mean that HTTP is the only use case
for protocol negotiation.

One of my goals is to make it possible for an email server to
multiplex HTTP, SMTP, LDAP, IMAP, and/or POP all over port 443 on the
same host (with one hostname). So, for example, when a MitM sees a
connection to example.org:443, the MitM doesn't know which of those
protocols are being used, without doing traffic analysis. Then, the
next step is to add features to TLS to make traffic analysis much more
expensive and/or potentially impossible. I have talked to one large
email provider already about doing the first part (multiplexing all
email protocols over 443), and I got a pretty positive response. I
don't know if they would be willing to do the second part to make
traffic analysis difficult. But, I think email providers of the
Lavabit-like predisposition *would* be likely to consider adopting
anti-traffic-analysis features, because those features are likely to
be somewhat expensive in terms of bandwidth used.

I think doing more to prevent traffic analysis in the messaging space
(including, but not limited to, email) is a very important part of the
perpass effort. Without it, we help enable attackers with global
resources to infer social networks through traffic analysis, even when
the traffic is encrypted. By making it difficult for an adversary to
determine when you are sending a message, and when you are receiving a
message, we make their inference much harder and hopefully
impractical.

Again, if the ALPN extension in the ClientHello was empty and meant "I
prefer HTTP/2 if you support HTTP" then I wouldn't have any objection.
However, currently the ALPN extension effectively allows arbitrary
application data to be sent in the clear, even though it is intended
to only allow protocol negotiation. We've already seen how, in the
case of http2-tls-relaxed, it is tempting to extend ALPN in ways we're
not intended it to be used, with negative results. I object to that,
because it isn't safe.

I also support NPN is because it has a much higher safety margin.
Again, you can see the additional safety margin that NPN has over ALPN
by looking at the analysis of the http2-tls-relaxed I did. Although we
seem to all agree that negotiating http2-tls-relaxed is an unsound
idea in general, the point still stands that encrypting the
information in the handshake provided defense-in-depth against a
serious issue.

> If hiding that

Actually, standardizing NPN would speed up the adoption of TLS 1.3,
because we wouldn't waste time trying to encrypt ALPN. We may want to
change how NPN works in TLS 1.3, and I am all for that. However, after
thinking about all the possibilities I could come up with, ultimately
if we're going to encrypt the protocol negotiation information in TLS
1.3, the negotiation will have to work more like NPN (server offers
protocols, client chooses one) than ALPN (client offers protocols,
server chooses one). So, adopting ALPN now, and then trying to fix
ALPN in TLS 1.3, would mean that browsers would go from NPN to ALPN
back to something very much like NPN. So, if anything is slowing down
work on TLS, it is actually ALPN itself.

> done as an extension to tls1.2 or earlier.

I think it is likely that all of "TLS 1.3" will be effectively a set
of extensions to TLS 1.2 and earlier anyway. One reason is that we've
already seen evidence of widespread intolerance to version 0x0304 in
the ClientHello: 10% of hosts surveyed, according to [1]. The second
reason is that it is easier to prototype new features as extensions
than trying to implement everything all at once. The third reason is
that some people already have plans to backport at least some "TLS
1.3" features to earlier versions.

> My reasoning there

I think your prediction is accurate, in that TLS 1.3 deployment will
be much faster than TLS 1.2 deployment. However, I doubt TLS 1.3
deployment will be widespread enough any time in the next 5-10 years
for browsers to be willing to degrade performance or security when
falling back to TLS 1.2 and earlier. That means we should plan on 10+
years of unencrypted ALPN in the ClientHello from all major browsers,
if we standardize unencrypted ALPN now.

[0] tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-02
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48

Cheers,
Brian

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQEcBAEBAgAGBQJSqH77AAoJEC88hzaAX42illgIAJltllnhLB3xGbHF/l6ul3nU
> Mzd8kvF9W27zRoGg0L1noxfQEawGyOjfRFxGXVO3BYHvXMSIfpAOC5vKWPnY/Hlc
> T2ZkklFk9bTq/b7PIJlmSlPTPqBBUCHlZkxxzlO5GeGwjXahOS7M+kc20/ufMHKG
> UGScMtzV5cx3fDQBAPBXjU5w9WHNz0LnLrti9q682g11a4nyRNKvPuaa8ujr4Ona
> dDtGKIk6ITr6DthO5IrhTEdRpR9/AgpR8WrXslMTKldELw6Inf4dBKOOkOJtnptA
> OTbtozBtlyvMQCHSxoVEb0FS5AgXFvTVL9t3SY/1BcYmzvbjvYl/XP1kNI8VTS4=
> =JATC
> -----END PGP SIGNATURE-----

---

From: Brian Smith <[email-masked]>
Date: Wed, 11 Dec 2013 16:58:16 -0800

> AD for advancement. You should of course feel free to reraise your objections

Thanks for the response Eric.

I can understand that the chairs may not think it is appropriate to
re-open the issue at this time. It isn't surprising, because you have
lobbied for ALPN and against NPN, and you've also said that it is
important for Cisco (the other chair's employer) to have its
inspection appliances capable of learning which protocol is being used
on TLS connections.

But, don't you think it would be better for the whole working group to
make that determination, instead of just the chairs? I think that if
you simply asked the working group if we (still) have have a
consensus, and the consensus is "go ahead with ALPN," then the whole
issue would be resolved within a week or two, and there would be no
trouble with IETF LC. But, if we don't verify that we actually have a
consensus now, then during IETF LC there will be doubt about whether
we still have a consensus.

I remember somebody once saying that, when we have authority, it is
important to avoid not just impropriety, but also the *appearance* of
impropriety. We as a working group have the authority and
responsibility to everybody that uses IETF protocols and products
based on TLS to make sure we've made good decisions and achieved
consensus. So, I still think it is important, before advancing the
document to IETF LC, that we clarify and verify that we actually have
a consensus.

Thanks again,
Brian

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 11 Dec 2013 17:21:48 -0800

Brian,

To me, the ALPN vs. NPN debate is like emacs vs. vi and Linux vs.
FreeBSD. We can talk passionately about it forever, but at some point
we need to make a decision and move on.

On Tuesday, Nov. 5, 2013 I was in the two sessions at IETF 88
Vancouver where ALPN was discussed. I witnessed several people spoke
in support of you after you spoke at the TLS WG session. The strange
thing is that some of those people also attended the httpbis WG
session that morning and heard Stephan Friedl's presentation of ALPN,
but none of them raised any objection then. This seems to imply they
were also willing to accept ALPN, until you tried to reopen the issue.

Wan-Teh Chang

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Dec 2013 18:44:04 -0800

> were also willing to accept ALPN, until you tried to reopen the issue.

Some people said to me that they were "willing" because the TLS chairs so forcefully pushed the WG in one direction, there was no reason to discuss it any further. The chair's message from yesterday despite the large number of voices in support of re-opening makes that resignation seem more appropriate.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Dec 2013 18:51:15 -0800

On Dec 11, 2013 6:44 PM, "Paul Hoffman" <[email-masked]> wrote:
> Some people said to me that they were "willing" because the TLS chairs so
forcefully pushed the WG in one direction, there was no reason to discuss
it any further. The chair's message from yesterday despite the large number
of voices in support of re-opening makes that resignation seem more
appropriate.
And yet fixing Lucky 13, killing RC4 weren't on the agenda where chairs
were willing to push. Cui bono?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Dec 2013 10:58:35 +0800

Brian,

You write:

  trouble with IETF LC.

This is the purpose served by the WGLC, which ended in September.
You are asking for yet another call for consensus; this would be appropriate
if there were materially new information available to the WG which
became available after WGLC (otherwise, people could just keep
asking for consensus calls).  Whether this is in fact the case is a
question for the chairs and the ADs.

We consulted with the AD prior to taking this action, so perhaps he
will respond to you separately.

-Ekr

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 12 Dec 2013 13:32:14 +0000

(not taking any sides but stating how it looks like. I personally do not
favor one over the other)

Hi Eric,

"if there were materially new information available to the WG"

I think Brian made a good case that 'materially new information is
available to the WG which became available after the WGLC'.
(This is where the chairs disagrees with Brian and others on the list).

It appears you are pushing ahead with something that the majority in the WG
does not agree with _today_. (They might have agreed
with it when the WGLC happened but they no longer agree - because of new
information which became available).

Nobody is saying that ALPN should be shelved. What people like to see is to
have a vote at IETF89 I guess.

regards,

ralf

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Dec 2013 14:42:23 +0000

Hi Ralf

I don't think this is the majority of the WG. Those who argued for ALPN are pretty much quiet now.

Also, votes or hums at IETF89 won't change anything, because the chairs can only say at a meeting, "the sense of the room seems to be XXX, so we'll confirm this on the list". We're on the list now, so we might as well discuss it now. No reason to delay this one by another three months.

I preferred ALPN for the following reasons:

  *   ALPN leaks very few bits of relevant information. For starters, it's HTTP/1 vs HTTP/2, which is not interesting at all, as they convey the same information. There are suggestions to place more things there, like various mail protocols. Whether that happens or not, knowing that someone is reading mail rather than browsing the web is a small amount of information. This should be balanced against:
  *   NPN is a huge change to the state machine. ALPN is simple and straightforward.

I don't think NPN would be a great disaster - I would implement whichever one is chosen, but I strongly prefer ALPN.

Yoav

On Dec 12, 2013, at 3:32 PM, Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>> wrote:

(not taking any sides but stating how it looks like. I personally do not favor one over the other)

Hi Eric,

I think Brian made a good case that 'materially new information is available to the WG which became available after the WGLC'.
(This is where the chairs disagrees with Brian and others on the list).

It appears you are pushing ahead with something that the majority in the WG does not agree with _today_. (They might have agreed
with it when the WGLC happened but they no longer agree - because of new information which became available).

Nobody is saying that ALPN should be shelved. What people like to see is to have a vote at IETF89 I guess.

regards,

ralf
[https://mail.google.com/mail/u/0/images/cleardot.gif]

On Thu, Dec 12, 2013 at 2:58 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

You write:

-Ekr

On Thu, Dec 12, 2013 at 8:58 AM, Brian Smith <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, Dec 10, 2013 at 10:30 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

Email secured by Check Point

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 12 Dec 2013 17:08:41 +0100

On Thu, 2013-12-12 at 14:42 +0000, Yoav Nir wrote:

>       * ALPN leaks very few bits of relevant information. For
>         starters, it's HTTP/1 vs HTTP/2, which is not interesting at
>         all, as they convey the same information. There are
>         suggestions to place more things there, like various mail
>         protocols. Whether that happens or not, knowing that someone
>         is reading mail rather than browsing the web is a small amount
>         of information. This should be balanced against:

I also prefer ALPN, for the additional reasons, that (1) uses the
standard TLS extension mechanism, and (2) a load balancer, or
super-server can distribute the protocols indicated in ALPN to various
(different) servers. That cannot be done in any efficient way using
NPN. 

While I believe privacy concerns are important, in that case nothing is
revealed to an adversary that was not available before (i.e., the
service was always known due to TCP port number). Moreover applications
that require privacy can always use steganography and advertise a phony
protocol.

TLS has specific design goals, and hiding the service and the connecting
peers were never among them (don't say I agree with that). Adding both
is a major redesign, which I agree with the calls to be postponed to TLS
1.3 (or 2.0). Otherwise if every extension designs its privacy goals
differently, we get a protocol full of hacks that doesn't allow to be
improved in a sensible way.

regards,
Nikos

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 12 Dec 2013 20:55:32 +0000

Hi. Watching this list since IETF 88, I note with some interest Eric's
and Sean's responses to Brian's email raising profound concerns about
the consensus call on ALPN and asking for a reconsideration and new
consensus call.

With the greatest of respect, saying no new 'substantive' or
'material' information which might warrant a re-examination of this
issue has come to light since early September - in the light of the
Snowden revelations and the IETF 88 "Hardening The Internet" Technical
Plenary and its landmark discussions, mind you - is quite plainly wrong.

It could not be more significant to the internet in general, and this
working group in particular. We know Nation State Adversaries
[hereinafter NSA] are actively attacking the internet via
surveillance; we know that they laugh in the face of existing TLS
deployments; and we know they have backdoored and stymied multiple
encryption products and standards before.

I'm certain neither the chairs nor ADs would wish for their integrity
and motivations to be questioned - but one could be forgiven for
perceiving their responses as blatant railroading. We already know the
NSA have previously manipulated cryptographic standards to weaken them
to their advantage, and it worries me that any such manipulation (were
it to occur) would look exactly like this, and that the chair and ADs
would be obvious targets. That troubles me. It should trouble you, too.

It was clear from IETF 88 that the advantage of the open process in
developing cryptographic standards is trust. We should never squander
that trust by acting rashly and standardising a metadata extension to
the most widely-used cryptographic protocol without properly
addressing the very real concerns raised - and, where necessary,
stopping, rewinding, pausing, and reconsidering to make sure that
whatever we decide, we do so as carefully and knowledgeably as possible.

With that in mind, I note the comments of others, and shall add my
own. I'll try to keep my thoughts to bullets here.

The core issue:
• Using ALPN clearly identifies encapsulated protocol metadata to Eve.
• Using NPN does not.
  - The most widespread NSA attacks, by far, are passive eavesdropping.
  - Metadata = surveillance¹.
    · Even small amounts of metadata can be surprisingly dangerous.
    · Especially in aggregate.
  - How much of a vulnerability is knowing what protocol is inside TLS?
    · Passive target fingerprinting
    · Known-plaintext = potential trouble spot for wobbly stream cipher?
  - Where practical, we should design protocols to protect metadata².
  - Any protocol might use it, NOT just HTTP/1 vs. HTTP/2:
    · Example: WebSockets, already live in-the-wild [NPN, often w/SPDY].
    · Many, many other protocols use TLS to protect them too.
    · Some other protocols also use TCP/443; firewalls tend to allow it.
    · ALPN/NPN are both apt solutions for them to identify their nature.
    · If you want to keep it just to HTTP/1 or HTTP/2, say so with MUST.
      * And then don't we only need one bit? ;)

• Where might ALPN be better than NPN?
  - Deployment:
    · Simple. Hard to overcomplicate TLS 1.2 extension with plaintext.
  - To TLS endpoint server:
    · Maybe faster? How much faster?
  - To an untrusted third party:
    · Protocol filtering firewall. (notably, a Great Firewall)
    · NSA, running Blue Coat, Narus or X-KEYSCORE en masse.
    · Simplifies stream reconstruction, especially with multiplexing
      * Much worse for Tor. Tor would have to lie about ALPN.
  - To a trusted third party that doesn't speak TLS e.g. load balancer:
    · Identify encapsulated protocol, plaintext, without speaking TLS.
    · When is that useful? Multiplexed TCP/443 encapsulating protocol?
      * But why TCP/443? Because of protocol filtering firewalls.
        + They stop stuff working.
        + Arguably this is what firewalls are supposed to do.
        + As above: Not all firewalls are authorised/desirable.
        + Compare interaction of IPv4 exhaustion/NAT/inbound.
      * But ALPN lets protocol filtering firewalls see inside!
        + Benefit of TCP/443 muxing removed by ALPN firewall support.
        + Those with something to hide must lie about ALPN if mandatory.
      * So we might as well just use another TCP port. Or another DNS.
        + Interactions with SNI. Future TLS 1.3 SNI encryption?
        + Interactions with DNS/DNSSEC/DNScurve or something else?
      * Am I missing something here? WebSockets?
      * In big load-balancer, would TLS endpoint do better? Don't know.

• Where might NPN be better than ALPN?
  - Deployment:
    · Negative: Significantly more complex than ALPN.
    · But widely deployed already, thanks to SPDY drafts and WebSockets.
    · Patches already available for numerous TLS libraries.
  - To TLS endpoint server:
    · Maybe slightly slower? How much slower?
  - To an untrusted third party:
    · Both firewall and NSA have to guess protocol via traffic analysis
    · Complicates stream reconstruction, especially with multiplexing
      * Tor would be able to actually use NPN, potentially?
  - To a trusted third party that doesn't speak TLS e.g. load balancer:
    · Can't identify encapsulated protocol without speaking TLS/keys.
    · When is that useful? Scenarios which ALPN disallows if supported.

• Whatever picked, we're stuck with it, if TLS 1.2 still supported.
  - The HTTP/2 effect. Huge.
  - Need to consider in light of TLS 1.3 as well.
    · Hard to deprecate ALPN if firewalls filter lack-of-ALPN.
  - But TLS 1.3 wants to encrypt as much of the handshake as possible³.
    · This goal is in direct conflict with more plaintext metadata.
    · Suggestive that TLS 1.3 perhaps MUST NOT support ALPN?
    · So why add it now, to have a really hard time binning it later?
  - Bigger handshake for implementing both. Pick one good one.

• Proposal to implement ALPN & just lie as standard practice:
  - I think that proposal is silly.
  - We'd need to implement NPN as well, later.
  - Wouldn't we be better off just implementing NPN instead?

I personally lean strongly towards NPN myself, for the above reasons.

Others will no doubt have comments on my reasons, or have different
reasons, and may or may not come to the same decision.

Most importantly, whatever is ultimately chosen, I want it to be
chosen openly, transparently, and with reasons like the above, and
everything new that has come to light since the initial consensus
call, properly and publicly considered. Thank you.

___
1. A snappy comment courtesy of [Schenier]
<https://www.schneier.com/blog/archives/2013/09/metadata_equals.html>;
also, comments at IETF 88 Technical Plenary.
2. [Perpass] IETF 88 T/P Hum; resulting proposed BCP
<http://tools.ietf.org/html/draft-farrell-perpass-attack-00>
3. Proposed updated TLS WG charter drafts; IETF 88 discussions.

- -- 
/akr

---

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Thu, 12 Dec 2013 21:22:09 +0000

Brian,

By intent, ALPN was drafted to be a standard, run-of-the-mill TLS Extension with no changes to the fundamental extension model or state machine of TLS implementations.  So yes, it is not HTTP-specific, no disagreement there.  The original ask from the HTTP/bis working group was for a facility to indicate protocol choice between HTTP/1 and HTTP/2, but both ALPN and NPN are not limited to HTTP protocols only.

We anticipated the provisioning of multiple services on a single port on a single host as you describe and under those circumstances ALPN provides what I feel could be a couple of security and server management features over NPN.  First, ALPN does not require the server to disclose all the protocols it supports which is what NPN requires.  With ALPN an attacker could make repeated client requests to the host probing for different protocols but ALPN makes it harder for an attacker to determine the complete list of protocols exposed on a single host/port combination.  Secondly, with NPN the server side cert has been chosen before the protocol has been determined which would pretty much require all the services exposed on a single host/port combination with NPN to use the same cert.  With ALPN, as with SNI, the protocol is determined prior to certificate selection so administrators could continue to use different certs for different services/protocols if they so desire.

Given that the server publishes its list of supported protocols in the clear in NPN, I'd suggest that even a passive attacker could figure out the protocol in use with little difficulty.  Traffic analysis is one approach but if an attacker knew which user agent the client was using to connect to the service, then the chosen protocol would be obvious from the user agent implementation.  It strikes me that protocols which use the STARTTLS mechanism to upgrade to a secured channel would probably require some modification on both client and server to initiate the connection in TLS with NPN or ALPN and the appropriate protocol identifier rather than starting in plaintext.

Finally, I don't believe that the TLS 1.3 effort is going to 'waste time figuring out how to encrypt ALPN', rather it appears to me as if TLS 1.3 is focusing on early encryption in the handshake which would cover ALPN, SNI and any other extension in use now or in the future.  

Thanks,

Stephan

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Brian Smith
> Sent: Wednesday, December 11, 2013 5:44 PM
> To: Stephen Farrell
> Cc: IETF TLS Working Group
> Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
> 
> >>> FWIW, I agree with you in general, but in this case the privacy leak
> >>> is non-existent if its only HTTP/1.1 vs HTTP/2.0 - since the binary
> >>> encoding and lack of head-of-line blocking in the latter will give
> >>> that game away anyway.
> >>
> >> traffic analysis will disclose what protocol is in use in this case?
> >
> > I believe so, esp since there's just http/1.1 and http/2.0 in question
> > (well, maybe spdy too for some time).
> 
> Hi Stephen,
> 
> You made this argument in two different threads, and I'll just reply in this
> one.
> 
> HTTP/1 vs HTTP/2 vs. SPDY. If ALPN were only capable of disclosing which
> version of HTTP you are speaking, I'd not be objecting so strongly to it.
> 
> However, the ALPN draft [0] isn't HTTP-specific. It happens to be the case
> that only HTTP-related protocol identifiers are currently planned to be
> registered, but that doesn't mean that HTTP is the only use case for protocol
> negotiation.
> 
> One of my goals is to make it possible for an email server to multiplex HTTP,
> SMTP, LDAP, IMAP, and/or POP all over port 443 on the same host (with one
> hostname). So, for example, when a MitM sees a connection to
> example.org:443, the MitM doesn't know which of those protocols are being
> used, without doing traffic analysis. Then, the next step is to add features to
> TLS to make traffic analysis much more expensive and/or potentially
> impossible. I have talked to one large email provider already about doing the
> first part (multiplexing all email protocols over 443), and I got a pretty positive
> response. I don't know if they would be willing to do the second part to make
> traffic analysis difficult. But, I think email providers of the Lavabit-like
> predisposition *would* be likely to consider adopting anti-traffic-analysis
> features, because those features are likely to be somewhat expensive in
> terms of bandwidth used.
> 
> (including, but not limited to, email) is a very important part of the perpass
> effort. Without it, we help enable attackers with global resources to infer
> social networks through traffic analysis, even when the traffic is encrypted.
> By making it difficult for an adversary to determine when you are sending a
> message, and when you are receiving a message, we make their inference
> much harder and hopefully impractical.
> 
> application data to be sent in the clear, even though it is intended to only
> allow protocol negotiation. We've already seen how, in the case of http2-tls-
> relaxed, it is tempting to extend ALPN in ways we're not intended it to be
> used, with negative results. I object to that, because it isn't safe.
> 
> Again, you can see the additional safety margin that NPN has over ALPN by
> looking at the analysis of the http2-tls-relaxed I did. Although we seem to all
> agree that negotiating http2-tls-relaxed is an unsound idea in general, the
> point still stands that encrypting the information in the handshake provided
> defense-in-depth against a serious issue.
> 
> > If hiding that
> > somewhat is the claimed benefit and if that diverted scarce WG
> > resources away from tls1.3 then I figure doing the work in tls1.3 is
> > better.
> 
> Actually, standardizing NPN would speed up the adoption of TLS 1.3, because
> we wouldn't waste time trying to encrypt ALPN. We may want to change
> how NPN works in TLS 1.3, and I am all for that. However, after thinking
> about all the possibilities I could come up with, ultimately if we're going to
> encrypt the protocol negotiation information in TLS 1.3, the negotiation will
> have to work more like NPN (server offers protocols, client chooses one)
> than ALPN (client offers protocols, server chooses one). So, adopting ALPN
> now, and then trying to fix ALPN in TLS 1.3, would mean that browsers would
> go from NPN to ALPN back to something very much like NPN. So, if anything
> is slowing down work on TLS, it is actually ALPN itself.
> 
> > I really like the idea of meeting that requirement. But again it seems
> > to me like it'd be better baked into tls1.3 and not done as an
> > extension to tls1.2 or earlier.
> 
> I think it is likely that all of "TLS 1.3" will be effectively a set of extensions to
> TLS 1.2 and earlier anyway. One reason is that we've already seen evidence
> of widespread intolerance to version 0x0304 in the ClientHello: 10% of hosts
> surveyed, according to [1]. The second reason is that it is easier to prototype
> new features as extensions than trying to implement everything all at once.
> The third reason is that some people already have plans to backport at least
> some "TLS 1.3" features to earlier versions.
> 
> > My reasoning there
> > assumes that we figure tls1.3 will be widely deployed more quickly
> > than previous updates due to the collective win of running http/2.0
> > over tls1.3. Doing a lot of things in both
> > tls1.3 and as extensions to earlier versions also seems less likely to
> > work out, given that we all have limited cycles.
> >
> I think your prediction is accurate, in that TLS 1.3 deployment will be much
> faster than TLS 1.2 deployment. However, I doubt TLS 1.3 deployment will be
> widespread enough any time in the next 5-10 years for browsers to be willing
> to degrade performance or security when falling back to TLS 1.2 and earlier.
> That means we should plan on 10+ years of unencrypted ALPN in the
> ClientHello from all major browsers, if we standardize unencrypted ALPN
> now.
> 
> >> TLS 1.2 with cleartext ALPN, based on how we understand negotiated
> >> TLS today, then compliant clients may have a strong incentive to
> >> continue to send cleartext ALPN, so that they can negotiate with
> >> servers not yet capable of TLS 1.3.
> >
> > Yep, that is a good question to consider. I don't think I've seen it
> > addressed either, but maybe I missed that.
> >
> >> much of the handshake as possible (which i think it should be), then
> >> standardizing ALPN now seems to work against the goals of TLS

---

From: Bill Frantz <[email-masked]>
Date: Thu, 12 Dec 2013 13:52:56 -0800

>something that I'd definitely want to avoid.

Obviously, considering the code that is now being shipped, most 
browser people have held their noses and gone down the retry at 
lower level path. Functionality over the best security.

Of course until quite recently people thought that SSL3 was 
reasonably secure, so the odor wasn't quite as bad.

>viable thing for us to do.

I view the added latency as a plus. It gives sites an incentive 
to upgrade.

<rant>
We are now in the situation where much of the end-user security 
software is automatically upgraded regularly. The server side 
software is never* upgraded. To improve net security this 
situation has to change.

* Yes, it's a bit strong. Google, Facebook etc. are leaders in 
improving security. However, never applies to the embedded 
devices using HTTPS for configuration.
</rant>

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | If the site is supported by  | Periwinkle
(408)356-8506      | ads, you are the product.    | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032