IETF Floats Draft PRISM-Proof Security Considerations 75
hypnosec writes "PRISM-Proof Security Considerations, a draft proposal to make it harder for governments to implement and carry out surveillance activities like PRISM, has been floated by the Internet Engineering Task Force (IETF). The draft highlights security concerns as a result of government sponsored PRISM-like projects and the security controls that may be put into place to mitigate the risks of interception capabilities. Authored by Phillip Hallam-Baker of the Comodo Group the draft is however very sparse on details on how the Internet can be PRISM-proofed."
Not an IETF Draft (Score:5, Informative)
An IETF draft starts with "draft-ietf-". This is merely a proposal by a member of the IETF to discuss this subject.
Corrections (Score:5, Informative)
Anyone can submit an I-D for anything. With few exceptions they are uploaded automatically with no human review, zero buy-in, endorsement, weight..etc by anyone. This ID has not even been adopted by a particular WG.
Then theres question of what is it this draft proposes reads more like a hapazard list of one mans problems.
To be clear I'm not attacking the I-D I'm attacking the warped characterization of it by people who should know better.
Re: Not an IETF Draft (Score:2, Informative)
[Can't log in due to another slashfail, I wrote the draft]
Yeah, I did rather wonder about that when I got sent the Register article. They didn't even ask me for comment before publishing or I would have told them.
This is merely a summary I wrote of the traffic on a private list that we have been discussing PRISM on. It is not even all my work. And the main point is simply to set a baseline for the three drafts to follow so that we can avoid prolonged discussion of purported PRISM capabilities.
The next draft divides the problem space into two parts, first things that we already have good solutions for, second things that we need to improve on. Much of that is taken from the work I did on secure email in my book 'dotCrime Manifesto'. At the moment we have two email security solutions, neither of which is viable. S/MIME has ubiquitous deployment, PGP has mindshare. It does not matter how long we try, we are not going to get everyone on the Internet to use PGP. It is just too complicated for people to understand. And so is S/MIME. But there are parts of S/MIME and STARTTLS that we can just build on without modification. S/MIME message format works fine and many email clients can receive S/MIME encrypted mail without any horrid user issues. Key validation and distribution on the other hand is not done at all well. So we need a standard for a 'socket' that can fit into a MUA that allows them to access a module that does those well.
The idea of that draft is that there are four are five people who are working on innovative PKI schemes to address key distribution. But users don't want to have to bet on any one of those being the 'winner'. Plus we have lots of people who just want to hack cool crypto code into Thunderbird or the like. So if we define the interface between the two groups then we can both work in parallel and without wasted effort. And if there are enough people implementing sockets in MUAs then pretty much everyone can use encrypted email with their favorite mail client.
The third draft deals with key generation and proposes that we have a tool that generates keypairs and (optionally) submits them to some service that will be the gateway to the key distribution scheme. Although there are keygenerators out there, there are issues that just make them unsuited and none offers a good way to backup a private key or transfer it into another device. [No encrypting your private key with a human readable password with 40 bits of entropy is not a good approach). That draft goes beyond the current capabilities but is something I think we can all agree on as a common infrastructure.
The final part will be my solution to the researchy part of the problem. I doubt mine will be the only one. I am looking at building on the ideas in Google's Certificate Transparency but without the transparency proofs in the cert part which I find silly and for email is unnecessary since we do not worry about shaving a hundred milliseconds off latency. There is also a second layer of notaries, the inter-notary infrastructure.