Re: [TLS] ALPN concerns

[Brian Smith <[e-mail]>]

On Wed, Nov 6, 2013 at 10:00 AM, Xiaoyong Wu <[e-mail]> wrote:
> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.

Xiaoyong, thank you very much for sharing that with us! That is
incredibly useful.

In the thread "Final nail in the coffin for cleartext SNI/ALPN in TLS
1.3," Yoav Nir <[e-mail]> wrote:
> I think it would actually be worse than that. Browsers don't want
> reconnect fallback. So whatever TLS 1.3 looks like, the ClientHello
> that browsers send will be such that it can be accepted by at least
> TLS 1.0 servers (and there are plenty of those around). And as
> others have mentioned, SNI is needed in many cases. Without it,
> https://www.gmail.com will give you a certificate error.
>
> So you might have a clientHello that leads to super-duper TLS 1.3,
> but to avoid the need for fallback, you include the SNI (and
> presumably ALPN) in the ClientHello.

This is exactly right for SNI. Even if we define a new replacement for
SNI, browsers will still be sending SNI in the clear for the next 10
years. We should still try to work toward a long-term solution to that
problem, but it isn't something that can be solved in the short term.

During the TLS WG session at IETF88, somebody commented that TLS 1.3
is supposed to solve the problem of encrypting information in the
ClientHello, so the plaintext vs. cleartext issue shouldn't be a
concern for ALPN. But, for the same reason we can't have any near-term
solution for encrypting SNI in the ClientHello, we won't have any
near-term solution for encrypting ALPN in the ClientHello that would
meet browsers needs.

Again, I want to emphasize that Firefox ALREADY solves this problem,
even without TLS 1.3, by implementing NPN and avoiding ALPN. If other
browsers just turned off ALPN then the problem of how to hide the
protocol negotiation information would be solved. As far as I've been
led to believe, ALPN exists primarily to allow MitM to more easily
inspect what protocol the application is speaking and possibly block
the application, with as low of a cost to the MitM as possible--i.e.
exactly the opposite goal of everything we discussed at IETF88 in
perpass and in other discussions. I still have a lot of trouble
understanding how we can agree in the IETF as a whole that we should
be trying to make attacks more difficult, even if we can't make them
impossible, but here in the TLS WG, we are literally going out of our
way to leak information in the clear unnecessarily.

I think that in many cases, traffic analysis that relies on timing
information will be able to tell with a high degree of accuracy which
protocol has been selected for use on the connection. However, traffic
analysis cannot tell us what protocols were offered but *not*
selected. Further, traffic analysis based on timing is more expensive
and less reliable than having the information given on a silver
platter. In some cases, traffic analysis vs. explicit plaintext
leakage might be the difference between reasonable doubt or not. In
other cases, the difficulty of discerning two protocols--whether you
are sending email (SMTP) or pinging the server to retrieve email
(IMAP) vs loading the login page (HTTP)--may increase the storage and
processing cost by an order of magnitude or more, if we can get it to
work. Personally, I'm disappointed to hear the arguments that it is
not worthwhile to consider trying to solve that problem in the context
of the design of ALPN, because we worry it is unsolvable. I feel like
we haven't even started trying to solve it yet, so I don't understand
why we're giving up so easily.

Further, I don't see a need to rush to a conclusion on ALPN for HTTP/2
given this chart:
https://github.com/http2/http2-spec/wiki/Implementations

At the time I write this, 11/13 support NPN. 6/13 support ALPN, and
there are plenty of implementations that can interoperate. Literally,
a higher number of products would have to do extra work to reduce the
privacy of their protocol and settings negotiation than the number of
products that would need to flip a single bit (or less) to have a
higher level of privacy protection for the protocol and settings
negotiation. (Note that it isn't even clear what settings negotiation
HTTP/2 may add to the protocol negotiation step, so we cannot even
debate how sensitive the information in that settings negotiation is
when trying to determine if leaking application data in the ALPN
extension is acceptable.)

Also note that the Mozilla line in the chart is a little misleading.
Patrick added ALPN support to a private copy of Firefox for the
purpose of the interop testing, which is I support. However, Firefox
doesn't actually support ALPN in our shipping product, only in
Patrick's special build. And, I would very much like to keep it that
way.

FWIW, I am working on an experiment for adding NPN support to
Thunderbird (an email client based on Gecko, like Firefox), so that
Thunderbird can speak SMTP, IMAP, POP, LDAP, and HTTP to a single
server on a single port, https://example.org:443/. One purpose of this
experiment is to demonstrate how we can get through networks that
block, or charge extra money for, email protocols while still allowing
HTTPS, without needing separate hostnames for each server. A second
purpose is to evaluate whether there are effective ways of making side
channel analysis for distinguishing the user's activity--sending email
vs retrieving email, for example--or even what product the user is
using--Thunderbird vs. Firefox--more difficult than we might first
suspect. I would appreciate it if the working group could give me some
more time to complete this experiment and/or help me with it, before
completely giving up on trying to protect the protocol negotiation
information in the handshake.

Also, if we can build a reliable 1-RTT handshake in TLS 1.3, then
there may be a design that allows us to remove protocol negotiation
from TLS completely, putting it back in the application layer. I will
be sharing a write-up of how this would work shortly. IMO, it is much
better to have the long-term solution for protocol and settings
negotiation be in the application layer, if it is reasonable to do so.
I am not one of those people that yell "layer violation" at
everything, but if we can avoid later violations in the long term,
then we should do so.

All that said, I am very grateful to the F5 team for sharing the
information to work around the interop issue that I originally
complained about in my ALPN Concerns email during IETF88. Xiaoyong set
a great example for us all and I hope that that kind of openness in
sharing information continues here on this list.

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