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

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi. Watching this list since IETF 88, I note with some interest Eric's
and Sean's responses to Brian's email raising profound concerns about
the consensus call on ALPN and asking for a reconsideration and new
consensus call.

With the greatest of respect, saying no new 'substantive' or
'material' information which might warrant a re-examination of this
issue has come to light since early September - in the light of the
Snowden revelations and the IETF 88 "Hardening The Internet" Technical
Plenary and its landmark discussions, mind you - is quite plainly wrong.

It could not be more significant to the internet in general, and this
working group in particular. We know Nation State Adversaries
[hereinafter NSA] are actively attacking the internet via
surveillance; we know that they laugh in the face of existing TLS
deployments; and we know they have backdoored and stymied multiple
encryption products and standards before.

I'm certain neither the chairs nor ADs would wish for their integrity
and motivations to be questioned - but one could be forgiven for
perceiving their responses as blatant railroading. We already know the
NSA have previously manipulated cryptographic standards to weaken them
to their advantage, and it worries me that any such manipulation (were
it to occur) would look exactly like this, and that the chair and ADs
would be obvious targets. That troubles me. It should trouble you, too.

It was clear from IETF 88 that the advantage of the open process in
developing cryptographic standards is trust. We should never squander
that trust by acting rashly and standardising a metadata extension to
the most widely-used cryptographic protocol without properly
addressing the very real concerns raised - and, where necessary,
stopping, rewinding, pausing, and reconsidering to make sure that
whatever we decide, we do so as carefully and knowledgeably as possible.

With that in mind, I note the comments of others, and shall add my
own. I'll try to keep my thoughts to bullets here.

The core issue:
• Using ALPN clearly identifies encapsulated protocol metadata to Eve.
• Using NPN does not.
  - The most widespread NSA attacks, by far, are passive eavesdropping.
  - Metadata = surveillance¹.
    · Even small amounts of metadata can be surprisingly dangerous.
    · Especially in aggregate.
  - How much of a vulnerability is knowing what protocol is inside TLS?
    · Passive target fingerprinting
    · Known-plaintext = potential trouble spot for wobbly stream cipher?
  - Where practical, we should design protocols to protect metadata².
  - Any protocol might use it, NOT just HTTP/1 vs. HTTP/2:
    · Example: WebSockets, already live in-the-wild [NPN, often w/SPDY].
    · Many, many other protocols use TLS to protect them too.
    · Some other protocols also use TCP/443; firewalls tend to allow it.
    · ALPN/NPN are both apt solutions for them to identify their nature.
    · If you want to keep it just to HTTP/1 or HTTP/2, say so with MUST.
      * And then don't we only need one bit? ;)

• Where might ALPN be better than NPN?
  - Deployment:
    · Simple. Hard to overcomplicate TLS 1.2 extension with plaintext.
  - To TLS endpoint server:
    · Maybe faster? How much faster?
  - To an untrusted third party:
    · Protocol filtering firewall. (notably, a Great Firewall)
    · NSA, running Blue Coat, Narus or X-KEYSCORE en masse.
    · Simplifies stream reconstruction, especially with multiplexing
      * Much worse for Tor. Tor would have to lie about ALPN.
  - To a trusted third party that doesn't speak TLS e.g. load balancer:
    · Identify encapsulated protocol, plaintext, without speaking TLS.
    · When is that useful? Multiplexed TCP/443 encapsulating protocol?
      * But why TCP/443? Because of protocol filtering firewalls.
        + They stop stuff working.
        + Arguably this is what firewalls are supposed to do.
        + As above: Not all firewalls are authorised/desirable.
        + Compare interaction of IPv4 exhaustion/NAT/inbound.
      * But ALPN lets protocol filtering firewalls see inside!
        + Benefit of TCP/443 muxing removed by ALPN firewall support.
        + Those with something to hide must lie about ALPN if mandatory.
      * So we might as well just use another TCP port. Or another DNS.
        + Interactions with SNI. Future TLS 1.3 SNI encryption?
        + Interactions with DNS/DNSSEC/DNScurve or something else?
      * Am I missing something here? WebSockets?
      * In big load-balancer, would TLS endpoint do better? Don't know.

• Where might NPN be better than ALPN?
  - Deployment:
    · Negative: Significantly more complex than ALPN.
    · But widely deployed already, thanks to SPDY drafts and WebSockets.
    · Patches already available for numerous TLS libraries.
  - To TLS endpoint server:
    · Maybe slightly slower? How much slower?
  - To an untrusted third party:
    · Both firewall and NSA have to guess protocol via traffic analysis
    · Complicates stream reconstruction, especially with multiplexing
      * Tor would be able to actually use NPN, potentially?
  - To a trusted third party that doesn't speak TLS e.g. load balancer:
    · Can't identify encapsulated protocol without speaking TLS/keys.
    · When is that useful? Scenarios which ALPN disallows if supported.

• Whatever picked, we're stuck with it, if TLS 1.2 still supported.
  - The HTTP/2 effect. Huge.
  - Need to consider in light of TLS 1.3 as well.
    · Hard to deprecate ALPN if firewalls filter lack-of-ALPN.
  - But TLS 1.3 wants to encrypt as much of the handshake as possible³.
    · This goal is in direct conflict with more plaintext metadata.
    · Suggestive that TLS 1.3 perhaps MUST NOT support ALPN?
    · So why add it now, to have a really hard time binning it later?
  - Bigger handshake for implementing both. Pick one good one.

• Proposal to implement ALPN & just lie as standard practice:
  - I think that proposal is silly.
  - We'd need to implement NPN as well, later.
  - Wouldn't we be better off just implementing NPN instead?

I personally lean strongly towards NPN myself, for the above reasons.

Others will no doubt have comments on my reasons, or have different
reasons, and may or may not come to the same decision.

Most importantly, whatever is ultimately chosen, I want it to be
chosen openly, transparently, and with reasons like the above, and
everything new that has come to light since the initial consensus
call, properly and publicly considered. Thank you.

___
1. A snappy comment courtesy of [Schenier]
<https://www.schneier.com/blog/archives/2013/09/metadata_equals.html>;
also, comments at IETF 88 Technical Plenary.
2. [Perpass] IETF 88 T/P Hum; resulting proposed BCP
<http://tools.ietf.org/html/draft-farrell-perpass-attack-00>
3. Proposed updated TLS WG charter drafts; IETF 88 discussions.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSqiLDAAoJEOyEjtkWi2t6LQwP/RFF3it6pzgLh4Xcf53MjqLI
PZpKSOmzEiwcQgFDWuMKoorvW10bjZ0PWaRXx5Xvi5eMQ9gQZLFL8y18I4Ps03C6
vruBL/7Sv/ZZ3CSUY+qGHkpExQdAoPjlcokur8zV0LvqJIof2RuSqTmHq7hz2ITm
sKtWVl87ZJYDSOeFnsx8Aijse3Bc8Ow4v6ib8qpwxE5NgAamSiV3hPxiyXqxzRa7
BAhSuIviX3WDjWTvj5l6USMQaVQBDO5VXaT+4opUr+uZysuFMJNoOcu8asnD5IgB
4tKus3U2ZDgOpTf6BK1rcjfxnIsPBc9Er9mqYmAPi9Vm7zXPVz/wwjfVsZ5uRUoY
qyyIJS/OjNkQVbykZsuwRHpV6ZJ6AzaItrHeXGMluTrs/zvYughjA4aw0jfNDeO/
wlg70nomu9cxSDjPIshInYpkBGM1UKlpLMfMvO5ml7ERATZTUTXHkNhbbErcyfNq
7U3MENqDKG0jERjwt3dvM1g6+SZWu1UuSelZMwZd6jh84mmn1fJ9A0tnLGDxJQ64
QGHKO/g55GRL6q6T+dVTGibuqrwaKpaL4R3zuWeBB80d2URIEMQXxTxlqpVSYCr1
khd5m+WHOMPgRMuITW4dWxvSXgIAGkyMxWOtb711dPL8BEBNqvGVTQPNIPsPuuI4
0fIhJBRhRyHXvuJp6fj/
=cTIx
-----END PGP SIGNATURE-----