Re: [TLS] ALPN concerns

[Andrei Popov <[e-mail]>]

Hi Brian,

I totally agree that we need to encrypt more information in the TLS handshake, including the client cert and the contents of various extensions, such as SNI and ALPN. Unfortunately, the only way to make this information confidential in the existing versions of TLS is to incur additional round-trips (by using renegotiation, or otherwise exchanging messages after the TLS handshake is complete). This is one of the reasons why the TLS WG is pushing hard to make progress on TLS1.3.

> 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.

No, ALPN exists primarily to negotiate an application protocol without incurring extra round-trips, to allow the server to pick the application protocol and present the corresponding identity, and to align with the existing TLS extensions.

>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.

Correct, and NPN offers the list of the application protocols in clear-text, so it does not solve this problem.

> 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.

If we can avoid application protocol negotiation at the TLS layer without incurring additional round-trips, I am in full support. Looking forward to the write-up.

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Brian Smith
Sent: Monday, November 18, 2013 9:59 PM
To: Xiaoyong Wu
Cc: <[e-mail]>; Peter Gutmann
Subject: Re: [TLS] ALPN concerns

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) _______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls