Subject: [TLS] ALPN concerns

From: Brian Smith <[email-masked]>
Date: Tue, 5 Nov 2013 14:21:25 -0800

Hi all,

First, I apologize for sending this message at the last minute. I know
that the delay has caused some people come inconvenience and/or
consternation. I actually feel like I still don't have enough
information to make this email as helpful as it could be, but I think
waiting longer to collect more information is going to cause more harm
than good. I will follow up with more information as soon as I have
it.

I have been watching the efforts of my Google counterparts, who I work
on NSS with, regarding their deployment of ALPN and TLS 1.2.  I am
very concerned about the issues that they've run into where many web
servers are failing to handshake when the ClientHello message is
larger than 255 bytes. See [1] and [2] for some (not all) of the
information. Just yesterday, I got some numbers from Kurt Roeckx, who
relayed them from Ivan Ristic, that around 2.9% of the web servers
surveyed on the internet have this problem [3]. This is higher than
all the TLS 1.2/1.1/1.0 version intolerance measured in that survey
*combined*. That is well above the threshold where web browser makers
become very concerned.

Note that the failure mode for this is "the server does not respond."
This is the worst possible failure mode because it can only be dealt
with by implementing some kind of timeout for the handshake, that
falls back to a handshake with a smaller ClientHello. At Mozilla we
have extensive experience with this kind of timeout-based fallback
logic and we hate it due to too many false positives on poor networks.
It means that people on very poor connections lose the ability to
negotiate any TLS extensions, including in particular the SNI
extension and elliptic-curve-related extensions. In fact, we hate this
timeout-based fallback so much that we just removed it. (AFAICT, we
were the only browser to still be implementing it.) We don't want to
bring it back. Even if we were to decide to bring it back and accept
the false positives, a look at the list that Adam published ([1]
again) shows that we'd be impacting some very important sites with
horrible latency, which would almost definitely be unacceptable for
us.

We also know from prior experience that it is very difficult to get
people to deploy newer firmware and software updates to fix these
issues. Google tried a long time ago when similar issues were causing
False Start to fail, with the same failure mode. Adam Langley did
extensive lobbying to try to get these issues resolve, but they
weren't successful at convincing enough sites to do so. Consequently,
Google had to disable False Start for almost every website except
google.com, which was a major (30%, according to them) performance hit
for the affected sites. Note that Google also tried a blacklist
approach for dealing with False Start and that wasn't successful
either.

Consequently, it is very hard for me to see how I can interpret the
current information I have as anything other than "Firefox must make
sure its ClientHello stays under 256 bytes for some indefinite, but
almost certainly long, period of time." Right now, Firefox is doing
fine at staying under that limit. However, If we add support for ALPN
we're likely to go over that limit frequently. Further, even if we
could squeeze the ALPN extension in *now*, it may mean that we
effectively cannot deploy any more TLS extensions going forward, for
some indefinite period of time. That is unacceptable to me.

In particular, you may have seen the draft that EKR just posted [4].
Note how that draft adds significant amounts of information to the
ClientHello. When I talked about this with Patrick McManus and EKR, my
initial conclusion is that we can probably squeeze just enough
information into the ClientHello to stay under this artificial
256-byte limit, but only if we don't do ALPN. Or, put another way,
currently it looks like my choice is between the upcoming TLS 1.3
one-roundtrip handshake and ALPN, at least for an indefinite and
currently-unbounded period of time.

In the HTTPbis working group session earlier today, we noted that
besides certificate-related issues that are slowing HTTPS adoption,
there are significant performance concerns that also slow HTTPS
adoption. I view the TLS 1.3 one-roundtrip handshake as a way of
greatly improving the default level of TLS-induced latency, to help in
this regard. That is, I think that we can design the TLS 1.3
one-roundtrip handshake in a way that is safe and bulletproof enough
that we can have it enabled in the default configuration of all web
servers without requiring additional system administrator
configuration. In other words, we'll be able to do with a single
OpenSSL update what we haven't been able to do successfully enough
with False Start. I think that would be a huge win in the fight to
make encryption as pervasive as surveillance is.

I want to do whatever I can do to ensure we get that win, even if it
means not doing ALPN. We are very fortunate that every major browser,
and many server-side implementations, already implemented an
alternative to ALPN that avoids the compatibility risk: NPN. I don't
think NPN is perfect. But, NPN *works*, and it works *today*, and it
has been demonstrated to not cause any compatibility issues. So, from
a technical standpoint, NPN is the zero-risk, zero-effort choice and
thus greatly preferable.

Here at IETF 88 we're spending a lot of effort to figure out what to
do about the pervasive passive evesdropping problem by effectively
trying to figure out how to encrypt as much of the internet as is
feasible. I am having a hard time squaring this with the effect that
switching from NPN to ALPN would have. We're effectively asking web
browsers to *stop* encrypting information in the handshake that they
are currently encrypting. It seems backwards. I think it is well worth
considering, given what we've all read in the news between IETF 86 and
IETF 88, whether we should be extra, especially careful about leaking
anything in cleartext that we can possibly encrypt. Further, I think
we should be careful to avoid setting precedent for leaking more and
more cleartext information in protocols that are designed to be
secure. I hate slippery-slope arguments as much as anybody, but we've
actually already seen this happen in the HTTP WG, where people are now
suggesting that ALPN be used to negotiate additional information
beyond HTTP 1.x vs. HTTP 2.0. I feel like saying that it is OK to
provide a cleartext outlet for this information is likely going to be
a mistake analogous to how the TLS 1.1 spec was wrong in saying "This
leaves a small timing channel, since MAC performance depends to some
extent on the size of the data fragment, ut it is not believed to be
large enough to be exploitable" regarding the verification of MACs.
Just because we cannot find a problem now doesn't mean we won't find a
problem later. We should default to the safer choice.

Unfortunately, being at odds with the IETF TLS working group by
preferring to do NPN and not ALPN is a sucky situation to be in--for
me personally, and for my organization, and for others on this working
group. So, I would like to find some way for us to reconsider whether
NPN is really so bad that we (the TLS WG and implementers) must
immediately pay the costs of resolving the significant issues with
ALPN now, when we don't understand the full compatibility impact of
ALPN on current implementations and/or on our ability to deploy TLS
1.3 in the future.

I am very interested in what other implementers think about the issues
I brought up:

1. Is ALPN causing too many compatibility issues now?
2. Is it going to be difficult to deploy much-needed TLS 1.3
functionality later if we deploy ALPN first?
3. Is it really a good idea to have TLS encrypt less application data
instead of of more, especially considering that IETF and TLS 1.3 are
moving in the other direction overall.
4. Is it really problematic, other than the unfortunate politics, for
web browsers to carry on using NPN, either in addition to, or instead
of ALPN?

Thanks for your consideration.

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

[1] https://www.imperialviolet.org/2013/10/07/f5update.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=923696
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48
[4] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00#section-5.1

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 01:19:26 +0000

Hi

A few data points:

Currently (with NPN but without ALPN), the length of a ClientHello is about 17x bytes for both Chrome and FF, not including the hostname in SNI.

Removing NPN saves 4 bytes, and adding ALPN may add 10-20 bytes, and the SNI is unbounded anyways [1]. That doesn't usually get to you 255. But session resumption may add the session ID, which is about 32 bytes. 

Can we assume that the old BigIP don't support ALPN?  If so, you could avoid either ALPN or session resumption with a server that did not return ALPN. Wouldn't this solve the problem?

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Nov 2013 17:24:19 -0800

On 5 November 2013 14:21, Brian Smith <[email-masked]> wrote:
> I am
> larger than 255 bytes.

I can understand the need to avoid the ceiling in the short term, no
question.  But how much headroom is there?

Having some specific numbers would definitely help inform the
discussion.  Clearly, including SNI with a maximum-length hostname is
going to blow this limit, so the question is where we think the line
needs to be drawn.

Given information on sizes, there are other options available to us.
Changing to shorter ALPN strings, or even moving to binary identifiers
(which would be unpleasant, but probably manageable) are definitely
still possible.  And those are only the solutions that are constrained
to ALPN, if you are willing to look elsewhere, you might instead
suppress SNI instead for long hostnames.  After all,
http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/
created this problem for themselves.

If we're that close to the limit, then a great many of the advantages
of TLS1.3 are likely to be eliminated.  Most of the 0-RTT modes won't
work.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 01:35:35 +0000

One other thing: Microsoft has released IE 11 that has ALPN. So if ALPN makes TLS fail, then those 2.3% of websites are now inaccessible by Internet Explorer. That is one big reason to upgrade their BigIP box.

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Nov 2013 18:32:57 -0800

> going to blow this limit, so the question is where we think the line

To give an idea:

A TLS 1.2 ClientHello which lists all the authenticated ciphersuites
currently defined (no anonymous), EC curves and formats, and signature
algorithms, but no SNI, is 528 bytes.  So you can already be way over
255 bytes just with things already defined.

The TLS 1.2 Safari ClientHello in OS X 10.9 when connecting to
ssl.apple.com is 180 bytes, and that has SNI but no NPN or similar,
and a limited number of elliptic curves.

I think the Safari ClientHello is close to the minimum you would want;
that is, if your ClientHello is much shorter, you're probably missing
something more important than ALPN.  I would suggest allowing 30 bytes
for longer domain names.  So there's maybe 45 bytes to split between
ALPN, TLS 1.4, AEAD ciphers, new elliptic curves, and any other
feature that might be implemented in future.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 03:50:38 +0000

> feature that might be implemented in future.

Don't forget 32 bytes for session ID or any number of bytes for session ticket in resumption attempts. Now your 45 bytes are down to 13 or less.  

And as for domain names:
http://www.thelongestdomainnameintheworldandthensomeandthensomemoreandmore.com

---

From: Andrei Popov <[email-masked]>
Date: Wed, 6 Nov 2013 20:51:19 +0000

ALPN support in IE11 does not usually trigger the issue with unpatched F5 devices. The combination of cipher suites, TLS extensions, and ALPN protocol IDs that IE11 advertises is such that the ClientHello is typically shorter than 256 bytes. Longer server names passed via SNI can of course still push IE's ClientHello over the unpatched F5 device's limit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Tuesday, November 5, 2013 5:36 PM
To: [email-masked] list
Subject: Re: [TLS] ALPN concerns

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