Re: [liberationtech] [ipv6hackers] opportunistic encryption in IPv6
- Forwarded message from Tim tim-secur...@sentinelchicken.org - Date: Wed, 12 Jun 2013 09:34:11 -0700 From: Tim tim-secur...@sentinelchicken.org To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Hi guys, Long time lurker, seldom poster. I've read through this whole thread to date and just want to make a couple of comments. I'm reasonably sure that there is a potentially huge demand for passive attack protection for end users and enterprises. If this could be package-ready for Linux or FreeBSD then eventual deployment numbers could be considerable. Here, I just don't understand the logic. To me, encrypting without authenticating buys you absolutely nothing, except to burn CPU cycles and contribute to global warming. In the *vast* majority of networking technology we use, modifying data in transit is just as easy as passively reading data in transit, within a constant factor. (That is, in a big-O sense, these are the same difficulty.) S many different attempts at creating encryption protocols have utterly failed, and in most cases, it is because the designers have put the cart before the horse. They've started with the easy encryption problem rather than addressing the hard authentication problem. Indeed, you may be able to convince the world at some point to adopt opportunisitic encryption without authentication, since so many people don't understand that it doesn't buy you anything. But then they'll be shocked when the first guy writes and releases a MitM tool for it. Now, does this mean authentication is a black-and-white matter? No. Currently the whole world relies on SSL/TLS's PKI, which has been shown to be quite weak, especially in the face of government meddling. The ways in which SSL/TLS is used adds more weaknesses. But at some level, we get by. It is ok, to have weak authentication so long as you have a way to gradually build the trust of an entity's identity from that. As an aside: the idea embodied in CGAs is a powerful one: By making my address my key (signature), I'm implicitly binding my key to my protocol. However, CGAs address this problem at network layer, not at the human layer. So all it takes to bypass it is to MitM the protocol that hands out addresses for hosts. However, as a building block, it could be useful. Also, for those who aren't familiar with it, I strongly urge you to read up on Identity Based Encryption, where any string can be a public key, within a predefined authentication realm. Regarding the earlier comparison of different PKIs, I think we need something that merges some of the concepts of webs of trust with what we're using right now in the TLS PKI. Let me throw out an outline of what I think would work better and has a chance at adoption: - Certificates can be signed by multiple CAs. The number and quality of signatures determines the level of trust of a certificate. - The act of communicating with a node causes their key (or CA's key) to be signed and that signature to be published automatically. The logic is, if you trusted a node's identity once, then you should share the knowledge of that trust. This publishing process needs to be anonymized somehow. There needs to be incentives for publishing (think bitcoin). - Not everyone is a CA. Perhaps each major organization would act as a CA and sign certificates of other CAs. Users would leverage their org's trust network and not need to deal with signing at and endpoint level, though their own org would be aware of transactions with new external entities and autosign as necessary. Many of these ideas have obviously been proposed before and my outline is very generic, but meant as a starting point for discussion. Also, I realize that I've veered away from IPv6 specifically, but I think any discussion of authentication needs to start with people, not protocols, and then trickle down to the protocol level, not the other way around. Cheers, tim ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [ipv6hackers] opportunistic encryption in IPv6
- Forwarded message from Jim Small jim.sm...@cdw.com - Date: Tue, 11 Jun 2013 01:02:54 + From: Jim Small jim.sm...@cdw.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Hi Owen, The fundamental challenge for encryption is key distribution and management: * How do I authenticate the intended recipient(s)? This is a traditional challenge with many traditional solutions, all of which have tradeoffs, especially in M2M communications. * How do I distribute a key without letting anyone except the intended recipient(s) get it? DH pretty well solves this, no? Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. So I think there would be some value in a keying system that allows some kind of controlled federation without having to depend on pre-shared keys, PKI, or DNSSec. * How do I manage the key to periodically change it while keeping it confidential? Again, DH with PFS makes this a solved problem AFAIK. True - but only after the initial hurdle of having a pre-shared key or RSA key pair. * How do I notify the recipient if the key was compromised or is otherwise invalid? This doesn't seem all that hard so long as a rekey instruction is built into the protocol. I believe that's already the case with IPSEC SAs, no? Well - if we take DH, it's true once we've established a connection. What about if we haven't? Really the question I'm asking - if we have two independent parties, how do they validate each other without a trusted 3rd party? Current options: * pre-shared keys (but not scalable and keys tend to be weak to make it easy to share - keys are rarely if ever rotated) * PKI - good but complex and as Moxie Marlinspike has demonstrated with others many flaws, abused by governments * DNSSec - interesting one to watch but not really ready for wide spread use yet, needs greater adoption * Manual/3rd party CA - possible if one party trusts the other or in a service provider scenario Did I miss any viable wide spread options? I know there are lots of theoretical ones but I'm talking about significantly deployed ones - say used by at least 1 million parties. Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's direct- connect or whatever they call it product is quite a bit more viable. It depends on AD as a PKI distribution mechanism for authentication. DirectAccess is neat - but it's not exactly a break through. DA is just a service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good provisioning and automatic IPv4 tunneling. It's essentially a nice packaging of certificate-based IPsec leveraging Windows Active Directory provisioning. There are some good ideas in this paper. I just think there are some things missing - at least from my cursory reading of it. --Jim ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [ipv6hackers] opportunistic encryption in IPv6
- Forwarded message from Mark Smith markzzzsm...@yahoo.com.au - Date: Mon, 10 Jun 2013 21:10:06 -0700 (PDT) From: Mark Smith markzzzsm...@yahoo.com.au To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 X-Mailer: YahooMailWebService/0.8.146.552 Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com - Original Message - From: Jim Small jim.sm...@cdw.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Cc: Sent: Tuesday, 11 June 2013 11:02 AM Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 Hi Owen, The fundamental challenge for encryption is key distribution and management: * How do I authenticate the intended recipient(s)? This is a traditional challenge with many traditional solutions, all of which have tradeoffs, especially in M2M communications. * How do I distribute a key without letting anyone except the intended recipient(s) get it? DH pretty well solves this, no? Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. Don't think so anymore. Better-Than-Nothing Security: An Unauthenticated Mode of IPsec http://tools.ietf.org/html/rfc5386 Don't know if there are any implementations available. ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [ipv6hackers] opportunistic encryption in IPv6
This thread is ending, so I will limit further distribution, explicitly removing libtech. - Forwarded message from Jim Small jim.sm...@cdw.com - Date: Tue, 11 Jun 2013 04:27:33 + From: Jim Small jim.sm...@cdw.com To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Subject: Re: [ipv6hackers] opportunistic encryption in IPv6 Reply-To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Hi Mark, The fundamental challenge for encryption is key distribution and management: * How do I authenticate the intended recipient(s)? * How do I distribute a key without letting anyone except the intended recipient(s) get it? DH pretty well solves this, no? Yes and no. DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with. Don't think so anymore. Better-Than-Nothing Security: An Unauthenticated Mode of IPsec http://tools.ietf.org/html/rfc5386 Thanks - I was not aware of that. So BTNS is interesting - but it doesn't solve the above problems. Per the RFC, BTNS doesn't authenticate peers. It would seem that secure key distribution (maintain confidentiality, integrity, and authentication) remains a vexing problem. Here's an interesting question more relevant to the list and the paper though - are IPv6 CGAs useful? It seems like SeND is dead. But does anyone on the list think that CGAs could provide a useful competitive advantage for IPv6 over IPv4? Are these a useful building block? One thing I wonder about is a 64 bit hash is pretty small - I wonder if that is sufficiently complex to provide security for the coming decade+? PKI CAs using SCEP for enrollment/management work pretty well. If you could get a key pair from DHCP or as a function of using a directory service, use it to generate a CGA, and then use that just for authentication it would already be fantastic. Just being confident that an address is authentic and not spoofed is a huge improvement over the current state for Internet security. Thoughts? --Jim ___ Ipv6hackers mailing list ipv6hack...@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
