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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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). 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:
> 
> http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00

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.
> 
>> 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 
> TLS@ietf.org 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-----