On Thu, Apr 3, 2014 at 7:40 PM, Fred Baker (fred) <fred@xxxxxxxxx> wrote: > In view of recent issues in TurkTelecom and Indosat, it seems like the simplest reason would be to ensure that data putatively obtained from the IETF would in fact be obtained from the IETF. > > From my perspective, I would support a statement to the effect that IETF technology should be obtainable using https or whatever else we are recommending as "secure." I'd also be in favor of asking IETF contributors to obtain and use PGP keys and/or DKIM encodings to sign messages. And of asking that IETF tools not reformat email in ways that corrupt data that has been signed. > > To that end, I could imagine a requirement for some kind of roadmap. "The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and Z. After <date>, we require them to use Secure X, Secure Y, and Secure Z, and traffic originated by the IETF sites shall use such protocols." This sounds like a good idea. But we currently have a big problem in that the IETF has two email security standards, not one. And the two sides don't talk and this has created a stalemate that has blocked ubiquitous use of either. Today PGP has all the mindshare for encrypted messages and S/MIME has all the deployment. Neither is a success at anything approaching Internet scale. And neither is going to succeed in its current form. The only way forward is going to be to develop a new specification that is a worthy successor to both. Fortunately this is more a matter of optics than technical work. 95% of the work is already done. Any solution needs to comprise a message format, a trust model and a configuration model. And all need to be just as easy to use as regular mail is. 'Quite easy' does not cut it any more, today a security standard must have no impact at all or it won't be used. If we use the deployed infrastructure as a starting point and agree that any new scheme must support the trust models of both PGP and S/MIME, the way forward is pretty straightforward: Take the S/MIME message format and graft the PGP web of trust and fingerprint trust models onto it. What I have found is that this model is actually demonstrably more secure than either model on its own when measured against a time based work factor model. The reason to take the S/MIME message format is twofold. First it is the one that is already supported in billions of email clients. This means that if we build on the S/MIME model those clients can read encrypted messages without changing the client at all. That is a big plus since I have to be able to read any message I receive on my iPhone, iPad, and either of my two laptops and three desktops (total 7 machines). But I only need to be able to respond securely on two (though all is better of course). The other advantage to the S/MIME format is that it is a lot more mature than PGP/MIME and has been completely and thoroughly tested in the deployed mail infrastructure. I won't justify my trust model argument here since everyone who is approaching the problem in good faith should be willing to accept that the other side has good reasons for wanting their model. But in my podcast I show that a hybrid of both is superior. I explain why both is better here: http://www.youtube.com/watch?v=PBFnBpWkK8M (if people are interested I have put the whole design rationale onto YouTube). I do have code as well as specs. Right now I am working on a part of the design to make it easy to move keys from one client to another. This is necessary because if I am trying to read an encrypted message I need to be able to read it on any of my 7 machines. Right now that is a hand cranked operation but there is no reason that it can't be automatic. So I have a model that makes it easy to transfer the private decryption key to other machines. -- Website: http://hallambaker.com/