TLS NPN (Next Protocol Negotiation)
Over on the TLS WG mailing list at IETF there is some debate over the NPN (Next Protocol Negotation) TLS extension, which originated outside of TLS WG but is now starting to be brought up there for standardization. The thread starts at http://www.ietf.org/mail-archive/web/tls/current/msg06862.html Much of the debate centers around the idea that NPN will make it harder for network operators to know what protocols users are using over TLS and hence to block particular protocols while permitting others. One of the proponents (Adam Langley, who has been doing a lot of other fantastic work on making TLS better and more ubiquitous) mentioned the idea that Tor is an intended use case for this behavior, although there hasn't been any other explicit discussion of this. http://www.ietf.org/mail-archive/web/tls/current/msg06866.html The design, as is, was picked because the use cases considered were either ambivalent on this point [in effect, whether to reveal which service the client is interested in contacting earlier in the protocol] or favoured the privacy side (i.e. Tor). (Apparently the notion is that the protocol negotiation would happen late enough that the encrypted session is already established before the client and server decide which particular service the client wants to talk to, so you could multiplex, say, a web server, a Jabber server, a Tor server, and an IMAPS server all over tcp/443 and an eavesdropper wouldn't trivially be able to determine which one the client was communicating with -- except if side channels gave it away, of course.) I'm tempted to reply pointing out that _all_ uses of TLS represent at least potential support for a threat model in which a network operator is the adversary whom users are trying to defend against. So there's not much conceptually new about having TLS reduce network operators' control over traffic, although some of the people in the discussion seem to feel there is a qualitative difference between, say, keyword filtering and protocol filtering. Has anybody from Tor been working on NPN? -- Seth Schoen Senior Staff Technologist sch...@eff.org Electronic Frontier Foundationhttps://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TLS NPN (Next Protocol Negotiation)
Thus spake Seth David Schoen (sch...@eff.org): Much of the debate centers around the idea that NPN will make it harder for network operators to know what protocols users are using over TLS and hence to block particular protocols while permitting others. One of the proponents (Adam Langley, who has been doing a lot of other fantastic work on making TLS better and more ubiquitous) mentioned the idea that Tor is an intended use case for this behavior, although there hasn't been any other explicit discussion of this. It does seem like something we would try to use, but only if it were deployed widely enough so that we weren't the only ones using it. I'm tempted to reply pointing out that _all_ uses of TLS represent at least potential support for a threat model in which a network operator is the adversary whom users are trying to defend against. So there's not much conceptually new about having TLS reduce network operators' control over traffic, although some of the people in the discussion seem to feel there is a qualitative difference between, say, keyword filtering and protocol filtering. The point I would make is that its very likely that most services will continue to operate on their traditional tcp ports, regardless of NPN. Administrators hoping to be able to block protocols by a TLS fingerprint seem to be barking up the wrong tree. Anyone wishing to subvert their controls will use a custom TLS/stunnel bridge on an acceptable port as defined by their policy. I think this indicates that you are right. The more effecive way I have seen to do these sorts of controls is by policy enforcement on the software that the machines themselves can run, rather than on the network. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgprBA6gSIQVj.pgp Description: PGP signature
Re: TLS NPN (Next Protocol Negotiation)
On Tue, Aug 17, 2010 at 2:08 AM, Seth David Schoen sch...@eff.org wrote: [snip] I'm tempted to reply pointing out that _all_ uses of TLS represent at least potential support for a threat model in which a network operator is the adversary whom users are trying to defend against. So there's not much conceptually new about having TLS reduce network operators' control over traffic, although some of the people in the discussion seem to feel there is a qualitative difference between, say, keyword filtering and protocol filtering. s/network operator/someone with access to the network/ A protocol which places the service type outside of the crypto isn't _only_ vulnerable to the formal operators of the network it's just simply vulnerable. If you can trust that people with access to the network are trustworthy then why are you using TLS at all? If the IETF wishes to make the protocol subject to control by network operators then they should incorporate an explicit cryptographically secured backdoor (i.e. something similar to key escrow). This would be bad from a privacy and security perspective, but because it would be explicit it would still be arguably superior to INTENTIONALLY MAKING THE PROTOCOL IMPLICITLY VULNERABLE NOT ONLY TO THE PEOPLE YOU ARE EXPECTED TO TRUST BUT TO THE ENTIRE WORLD. ahem. I feel better now. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
