Re: Security for various IETF services

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Apr 3, 2014 at 7:40 PM, Fred Baker (fred) <[e-mail]> 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/