Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard

[Alyssa Rowan <[e-mail]>]

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

On 14/12/2013 12:47, Nikos Mavrogiannopoulos wrote:

>> [Limiting ALPN to HTTP/(1|2)]

To clarify, I specifically propose (Security Considerations?):

  It is NOT RECOMMENDED for a client using ALPN in TLS 1.2 to identify
  supported protocols other than HTTP/1 or HTTP/2: signalling that
  other protocols are supported could reveal more fingerprinting,
  targeting or application metadata in plaintext than is desirable or
  necessary.

  This caveat does not apply if the ClientHello is protected from
  passive eavesdropping [as in a future version of TLS].

(Subject to argument, of course.)

> I don't see any advantage in your proposal. Why restrict ALPN from
>  negotiating anything else than HTTP?

Because:
• It minimises plaintext fingerprinting.
  - Eve trivially knows every protocol Alice advertises support for.
  - Ideal if Eve wants to become Mallory and has a tailored exploit
    for one of them.
    · Real scenario: QUANTUM, EGOTISTICAL GIRAFFE, etc
  - Please let's keep that to a minimum, while it's still plaintext.
• Why use ALPN (or NPN!) for anything?
  - Why _indeed_ not use a port number? POP3 got one. Why not HTTP2?
  - Because of port-blocking firewalls disallowing all but port 80/443.
  - Many non-IETF protocol deployments bitten by this chose to use 443.
    · Tor
    · Several VPNs, including SSTP, and commonly OpenVPN in the wild
    · Skype [not that that's a _good_ protocol, just a common one!]
  - So multiplexing on 443 is considered fairly commonplace/desirable.
  - But DPI firewalls, even simple ones, can read ALPN if plaintext.
    · So they'd block those, too. Then what? Stop using ALPN? Lie in it?
• Most of all, because: it's HTTP/2 that needs it _right now_.
  - Other things can have it later, in TLS 1.3, when it's much safer.

At this point (post-IETF 88) if we were redesigning UDP or TCP, we'd
certainly consider encrypting the port numbers, if it were practical,
wouldn't we?

As far as your point that NPN is a bit of a hack, I agree.


It may be better to have ALPN in a limited fashion now, so that Martin
and the httpbis WG can proceed - I do not really want to delay their
fine work - and encrypt the whole ClientHello later in TLS 1.3.

Therefore, upon reconsideration, I withdraw my objection to ALPN
progressing to Proposed Standard.

I do wish for my caveat above to be noted under Security
Considerations, although this is of course subject to argument,
as others may not agree.

I apologise for any inconvenience caused.

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

iQIcBAEBCgAGBQJSrMEKAAoJEOyEjtkWi2t6JIcP/2UuGi+sg0dAKOnzBjzpxwo0
CvgVwES4WtF2QJEq7sCkXbYUIqW4uDeNAUy6D+vR5+Q407oPeIgR4IH9AzThFkpM
MR6cBP+yYyRpr0AFCtuupR77L0up9uLoSZxAgH7A4ot6s/fa2Vg1xtxE+C5/Sz4G
lPc6j8Rr3LnWlqH47kp+YxZAtAOa2pieWYDJlS8zK2Ulaf7I1mtAIy4MDAVrFYAN
Tye/LQLg485j0uXiDs3xErps0XJQKTT+dV3WtPMyNek6XjEQgHXQ9WbJE9t6F8W0
9Y5b2gzhoPoJ99OYTvZmYtdPdtFHHU+Hq6Q4ZuP64AMFviNTY7TQl3PD68WIiCyy
7feWHtl7Zb0Cbx8l+ZN3OV8BuUIcO3StcFnjaIu0jPP+Th2Wf9I+6045uqBq/Gmw
VmpMVR7+QDBLt15VnIuZNwdbo+e7Apin/YNnWxKg6PYakYXtCqQv+xWiexZooNn9
9vRnn3dzfLYMyjjd4sPDiEQ0toMIOQ133IToN6/TRU+VX00BnX5mZ8IMvRTwoVXz
ja1NJJUnZrYkS4P6/knR/8pQBONtVbQQ/JFhbmH2KtaUWdG4KnE9RSzCe3FVC9Um
iHeC/uY6ZTM521ISfCOH2+hj6Z3BDPm8WZCdLHB6T2pg+7ki+g8SbvpnaPy5RQ1L
N4TGPOysvUqmgcm9EDjT
=F2Gq
-----END PGP SIGNATURE-----