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

On Dec 14, 2013, at 10:35 PM, Alyssa Rowan <akr@akr.io> wrote:

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

Someone here suggested running email protocols (IMAP, POP3, and SMTP) over the same 443 port, distinguished by ALPN. In sites such as live.com or mail.google.com, you might even get the same information in HTTP/1, HTTP/2, IMAP, or POP3. Why should those be excluded?  How about having this in the security considerations:

   Implementers and document editors who intend to extend the protocol 
   identifier registry by adding new protocol identifiers should consider
   that in TLS versions 1.2 and below the client sends these identifiers
   in the clear, and should also consider that for at least the next 
   decade, it is expected that browsers would normally use these earlier
   versions of TLS in the initial ClientHello.

   Care must be taken when such identifiers may leak personally 
   identifiable information, or when such leakage may lead to profiling,
   or to leaking of sensitive information. If any of these apply to 
   this new protocol identifier, the extension SHOULD NOT be used in TLS
   versions 1.2 and below, and documents specifying such protocol 
   identifiers SHOULD recommend against such unsafe use. 

> 
>> 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-----
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls