Is Ubiquitous Encryption Technology on the Horizon?(networkworld.com)
networkworld.com
Is Ubiquitous Encryption Technology on the Horizon?
http://www.networkworld.com/community/node/63871
5 comments
The checks that CAs perform before issuing a cert can be pretty minimal - sometimes as simple as sending an email to an administrator address at the domain in question.
And do you trust all of the CAs who have certs on your machine? I did a quick check of the list on this box and I have no idea who most of these organizations are!
And do you trust all of the CAs who have certs on your machine? I did a quick check of the list on this box and I have no idea who most of these organizations are!
Changing which root certs your browser (or everyone's browser) honors is a less dramatic move than deprecating the world's best-tested crypto protocol and replacing it with something new.
I wonder if you could encrypt the IO and CPU operations from a VM. You would burn extra cycles, but you could publicly share computer resources.
I like Mark Handley's work, but the premise of this project seems off. It was true in 1999 that the easiest attacks were passive, but it is no longer true in 2010. Today, you are far more likely to have traffic intercepted --- through a hijacked DNS server, on a public wireless network, or via an application-layer flaw --- than you are to have traffic "sniffed". "Authentication" in the simplest sense, of "am I talking to who the address bar says I'm talking to" is the key problem that Internet crypto addresses.
Lightweight negotation and session reuse are good concepts, but SSL is trending in that direction anyways (soon you may be able to negotiate SSL once and then use the key material to send lots of out of band messages). Meanwhile, SSL is thoroughly tested (look at what Nate Lawson just did to OpenID for an example of why that matters) and well understood. The organizational/logistical challenge of how we tear the bloodsucking CA leeches off our applications boils down to "how can we get one more root cert added to IE and Firefox", which is a far, far easier problem to solve than forklifting out everyone's TCP stacks.
Apropos nothing: using a short TCP option to signal that the SYN+ACK contains a larger data payload is clever, although I wonder if they realize that SYN and SYN+ACK can already contain data, and that every TCP stack in the world will deliver that data to the application as soon as the 3WH is finished.