On Dec 14, 2013, at 10:35 PM, Alyssa Rowan <akr(_at_)akr(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls