GUADEC: Danny O'Brien on privacy, encryption, and the desktop [LWN.net]

GUADEC: Danny O'Brien on privacy, encryption, and the desktop

Posted Aug 4, 2010 21:42 UTC (Wed) by gmaxwell (subscriber, #30048)
In reply to: GUADEC: Danny O'Brien on privacy, encryption, and the desktop by farnz
Parent article: GUADEC: Danny O'Brien on privacy, encryption, and the desktop

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.

(Log in to post comments)

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.