| |||||||||||||
GUADEC: Danny O'Brien on privacy, encryption, and the desktopGUADEC: Danny O'Brien on privacy, encryption, and the desktopPosted Aug 4, 2010 16:40 UTC (Wed) by farnz (guest, #17727)In reply to: GUADEC: Danny O'Brien on privacy, encryption, and the desktop by gmaxwell Parent article: GUADEC: Danny O'Brien on privacy, encryption, and the desktop
Thing is that at a deeper level, we have IPSec. It has issues in a NATted world that need fixing (whether by enhancing NAT traversal of IPSec, or by going to IPv6 and removing NAT while we're at it), but it should in theory let all protocols that don't care use encryption by default, whether it's part of the protocol or not. Authentication is harder to solve (due to the inherent need for some sort of out-of-band proof of identity). And once you've solved the encryption problem once (by having all data that goes over IP encrypted in IPSec, even if it's then encrypted again inside the protocol for authentication purposes, ala HTTPS), there's no need for protocol designers to care.
(Log in to post comments)
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 4, 2010 17:16 UTC (Wed) by gmaxwell (subscriber, #30048) [Link] Due to the pervasiveness of NAT (as you mention) and layer-4 firewalling opportunistic user to user IPSEC isn't just a dream it's pure fantasy. It also has fairly high per-packet overhead while connection oriented security protocols like TLS have very little overhead past the initial setup.Even on the IPv6 internet it isn't there and doesn't appear to be forthcoming. Hell Path mtu discovery is absolutely mandatory with IPv6 because routers can't fragment and yet many sites which should know better (e.g. ISC) have been blocking needs fragment packets. IPSEC doesn't even have a chance. I support the notion of host-to-host IPSEC but we live in the real world and need to deal with real issues, and today IPSEC is a non-solution. And because it wasn't made mandatory with IPv6 it will likely always be vulnerable to downgrading attacks: simply block IPSEC and it will be disabled (either automatically and without the users knowledge or manually) and you can even plausibly claim an honest misconfiguration caused the blocking. Proposing that we solve this by using IPSEC is like proposing we boil the oceans. Effectively there is no party in control of IP, just a loose collective of voices at the IETF, and getting principled ethical action out of a consortium of many interests approaches impossible as the number of participants increases. Especially when some of those voices are, in fact, very interested in preserving an environment where surveillance is easy and cheap. But for applications there are single people and small groups with the power to make the right choices. They ought to stand up and make them, rather than waiting for the IP folks to solve it for them. Even in a future world where it IPSEC is viable the application level security still provides value because IPSEC's location in the network stack precludes it from providing the same security properties, you mention authentication which is a big one but their are additional properties like OTR's anti-non-repudiation which requires specialized interaction between authentication and crypto. Or many other cases where transport security isn't enough like email where the material should be stored in a secure form... so effort spent securing our applications will not be wasted.
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 4, 2010 20:30 UTC (Wed) by farnz (guest, #17727) [Link] On the other hand, the vast majority of protocol and application designers just don't care. "Boiling the oceans" by making IPSec work everywhere isn't easy - but it's a one-off big cost. Trying to round off every grain of sand by getting both protocol developers (who don't always see why it's important) and application developers (who often see it as extra work for no gain) to handle encryption in the protocol is similarly hard - but it's a lot of small costs, and we keep paying them day-in, day-out as we try to fix everything. Further, the nature of IPSec is that it gets implemented once per OS, and then it's not an issue for any application that uses that OS - indeed, I can blithely write encryption unaware code using the old BSD sockets API like I've always done, and benefit. If I have to get encryption right, not only is that extra effort that I'm going to fight back against (naturally - like most programmers, I'm lazy), but it also opens up lots of ways for me to get it wrong, whether we're talking design flaws like WEP's flaws, or implementation failures like the Debian OpenSSL flaw, which rendered keys effectively 16-bits long. At least with IPSec, people with more clue than I'll ever have have checked the design for mistakes, and another group of very clueful people will implement it, and fix the flaws found in the wild. And note that I'm not wedded to IPSec; if there was (say) a library that I could just link against and get all the nice security properties IPSec offers, that'd do just as well.
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 4, 2010 21:42 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Well thats why I made the statement above. They ought to care, and I think we have an ethical obligation to care. Some do care though by far not enough.
Host to host IPSEC is currently going nowhere, as has been the case for the past decade. Even with working support in the OS (and I don't believe that _any_ major operating system has working IPSEC OE out of the box, at least not without manually configuring certs for everything you want to talk to!), getting it enabled and getting the network to stop breaking it is a major challenge. I don't see how you can claim that something which is effectively vaporware has "nice security properties"
At least with the application oriented model we can make progress by winning one application at a time. Either way we have to win over people who don't care but winning over developers gives incremental progress all along the way, while trying to win over people running networks and people configuring hosts doesn't get you much until its done everywhere.
There are libraries that give you a sockets like interface to TLS, it's simple enough that many things support it optionally. To be immune to downgrading attacks it needs to be made mandatory.
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 5, 2010 10:52 UTC (Thu) by farnz (guest, #17727) [Link] But the people responsible for end-host software (Linux distro developers, for example) also ought to care about their users' privacy. Practically speaking, I've yet to come across a library that's a transparent replacement for BSD sockets (as in LD_PRELOAD or equivalent) so that I don't have to care about encryption - it just works. Instead, I have to remember to not use the libraries I've used for years, because if my quick hack becomes important, it might matter. At least with IPSec OE (which still needs work to fix, hence not ruling out other libc/kernel level routes), it doesn't matter if I forget to put in the SSL layer - it still gets encrypted. And if I need more complex solutions (authentication, repudiability etc), I can still put it in in the application layer. In the end, whether you try and tackle application and protocol developers one at a time, or distro developers, you're facing an uphill struggle - not least because (by and large), people don't see encryption as important. I believe that we're better off putting the effort into making all communications encrypted by default using some form of opportunistic encryption (not necessarily IPSec - an automatic SSL layer that just happens without application intervention would work, too, as would any other form of OE that doesn't require application developer support). And, of course, you are claiming that genuine vapourware (as in doesn't exist at all) has nice security properties. I am claiming that current deployments of IPSec have nice security properties, and I don't see how OE (the vapourware) breaks them.
|
|||||||||||||