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

[Brian Smith <[e-mail]>]

On Wed, Dec 11, 2013 at 7:04 AM, Stephen Farrell
<[e-mail]> wrote:
> On 12/10/2013 11:44 PM, Daniel Kahn Gillmor wrote:
>> On Tue 2013-12-10 17:19:10 -0500, Stephen Farrell wrote:
>>> 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 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).

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
> 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.
>
> But yes, that's prediction with which one could disagree.

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

>> And protocol negotiation is not only useful in the
>> HTTP/1.1?HTTP/2.0 use case.
>>
>>> I'd say focusing on tls1.3 and any privacy gains there is better
>>> 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.
>
> 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
>> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>>
> -----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-----
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)