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

["Stephan Friedl (sfriedl)" <[e-mail]>]

Brian,

By intent, ALPN was drafted to be a standard, run-of-the-mill TLS Extension with no changes to the fundamental extension model or state machine of TLS implementations.  So yes, it is not HTTP-specific, no disagreement there.  The original ask from the HTTP/bis working group was for a facility to indicate protocol choice between HTTP/1 and HTTP/2, but both ALPN and NPN are not limited to HTTP protocols only.

We anticipated the provisioning of multiple services on a single port on a single host as you describe and under those circumstances ALPN provides what I feel could be a couple of security and server management features over NPN.  First, ALPN does not require the server to disclose all the protocols it supports which is what NPN requires.  With ALPN an attacker could make repeated client requests to the host probing for different protocols but ALPN makes it harder for an attacker to determine the complete list of protocols exposed on a single host/port combination.  Secondly, with NPN the server side cert has been chosen before the protocol has been determined which would pretty much require all the services exposed on a single host/port combination with NPN to use the same cert.  With ALPN, as with SNI, the protocol is determined prior to certificate selection so administrators could continue to use different certs for different services/protocols if they so desire.

Given that the server publishes its list of supported protocols in the clear in NPN, I'd suggest that even a passive attacker could figure out the protocol in use with little difficulty.  Traffic analysis is one approach but if an attacker knew which user agent the client was using to connect to the service, then the chosen protocol would be obvious from the user agent implementation.  It strikes me that protocols which use the STARTTLS mechanism to upgrade to a secured channel would probably require some modification on both client and server to initiate the connection in TLS with NPN or ALPN and the appropriate protocol identifier rather than starting in plaintext.

Finally, I don't believe that the TLS 1.3 effort is going to 'waste time figuring out how to encrypt ALPN', rather it appears to me as if TLS 1.3 is focusing on early encryption in the handshake which would cover ALPN, SNI and any other extension in use now or in the future.  

Thanks,

Stephan


> -----Original Message-----
> From: TLS [mailto:[e-mail]] On Behalf Of Brian Smith
> Sent: Wednesday, December 11, 2013 5:44 PM
> To: Stephen Farrell
> Cc: IETF TLS Working Group
> Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
> 
> On Wed, Dec 11, 2013 at 7:04 AM, Stephen Farrell
> <[e-mail]> wrote:
> > 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).
> 
> Hi Stephen,
> 
> You made this argument in two different threads, and I'll just reply in this
> one.
> 
> I am not concerned about a MitM learning whether you are talking
> HTTP/1 vs HTTP/2 vs. SPDY. If ALPN were only capable of disclosing which
> version of HTTP you are speaking, I'd not be objecting so strongly to it.
> 
> However, the ALPN draft [0] isn't HTTP-specific. It happens to be the case
> that only HTTP-related protocol identifiers are currently planned to be
> registered, but that doesn't mean that HTTP is the only use case for protocol
> negotiation.
> 
> One of my goals is to make it possible for an email server to multiplex HTTP,
> SMTP, LDAP, IMAP, and/or POP all over port 443 on the same host (with one
> hostname). So, for example, when a MitM sees a connection to
> example.org:443, the MitM doesn't know which of those protocols are being
> used, without doing traffic analysis. Then, the next step is to add features to
> TLS to make traffic analysis much more expensive and/or potentially
> impossible. I have talked to one large email provider already about doing the
> first part (multiplexing all email protocols over 443), and I got a pretty positive
> response. I don't know if they would be willing to do the second part to make
> traffic analysis difficult. But, I think email providers of the Lavabit-like
> predisposition *would* be likely to consider adopting anti-traffic-analysis
> features, because those features are likely to be somewhat expensive in
> terms of bandwidth used.
> 
> I think doing more to prevent traffic analysis in the messaging space
> (including, but not limited to, email) is a very important part of the perpass
> effort. Without it, we help enable attackers with global resources to infer
> social networks through traffic analysis, even when the traffic is encrypted.
> By making it difficult for an adversary to determine when you are sending a
> message, and when you are receiving a message, we make their inference
> much harder and hopefully impractical.
> 
> Again, if the ALPN extension in the ClientHello was empty and meant "I
> prefer HTTP/2 if you support HTTP" then I wouldn't have any objection.
> However, currently the ALPN extension effectively allows arbitrary
> application data to be sent in the clear, even though it is intended to only
> allow protocol negotiation. We've already seen how, in the case of http2-tls-
> relaxed, it is tempting to extend ALPN in ways we're not intended it to be
> used, with negative results. I object to that, because it isn't safe.
> 
> I also support NPN is because it has a much higher safety margin.
> Again, you can see the additional safety margin that NPN has over ALPN by
> looking at the analysis of the http2-tls-relaxed I did. Although we seem to all
> agree that negotiating http2-tls-relaxed is an unsound idea in general, the
> point still stands that encrypting the information in the handshake provided
> defense-in-depth against a serious issue.
> 
> > 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.
> 
> Actually, standardizing NPN would speed up the adoption of TLS 1.3, because
> we wouldn't waste time trying to encrypt ALPN. We may want to change
> how NPN works in TLS 1.3, and I am all for that. However, after thinking
> about all the possibilities I could come up with, ultimately if we're going to
> encrypt the protocol negotiation information in TLS 1.3, the negotiation will
> have to work more like NPN (server offers protocols, client chooses one)
> than ALPN (client offers protocols, server chooses one). So, adopting ALPN
> now, and then trying to fix ALPN in TLS 1.3, would mean that browsers would
> go from NPN to ALPN back to something very much like NPN. So, if anything
> is slowing down work on TLS, it is actually ALPN itself.
> 
> > 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.
> 
> I think it is likely that all of "TLS 1.3" will be effectively a set of extensions to
> TLS 1.2 and earlier anyway. One reason is that we've already seen evidence
> of widespread intolerance to version 0x0304 in the ClientHello: 10% of hosts
> surveyed, according to [1]. The second reason is that it is easier to prototype
> new features as extensions than trying to implement everything all at once.
> The third reason is that some people already have plans to backport at least
> some "TLS 1.3" features to earlier versions.
> 
> > 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.
> 
> I think your prediction is accurate, in that TLS 1.3 deployment will be much
> faster than TLS 1.2 deployment. However, I doubt TLS 1.3 deployment will be
> widespread enough any time in the next 5-10 years for browsers to be willing
> to degrade performance or security when falling back to TLS 1.2 and earlier.
> That means we should plan on 10+ years of unencrypted ALPN in the
> ClientHello from all major browsers, if we standardize unencrypted ALPN
> now.
> 
> [0] tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-02
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48
> 
> Cheers,
> Brian
> 
> >> 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
> >> [e-mail] https://www.ietf.org/mailman/listinfo/tls
> >>
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.14 (GNU/Linux)
> >
> > iQEcBAEBAgAGBQJSqH77AAoJEC88hzaAX42illgIAJltllnhLB3xGbHF/l6ul3nU
> >
> Mzd8kvF9W27zRoGg0L1noxfQEawGyOjfRFxGXVO3BYHvXMSIfpAOC5vKWPn
> Y/Hlc
> >
> T2ZkklFk9bTq/b7PIJlmSlPTPqBBUCHlZkxxzlO5GeGwjXahOS7M+kc20/ufMHK
> G
> >
> UGScMtzV5cx3fDQBAPBXjU5w9WHNz0LnLrti9q682g11a4nyRNKvPuaa8ujr4O
> na
> >
> dDtGKIk6ITr6DthO5IrhTEdRpR9/AgpR8WrXslMTKldELw6Inf4dBKOOkOJtnptA
> >
> OTbtozBtlyvMQCHSxoVEb0FS5AgXFvTVL9t3SY/1BcYmzvbjvYl/XP1kNI8VTS4=
> > =JATC
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls