On Wed, Apr 9, 2014 at 10:01 PM, Randall Gellens
<randy(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:
At 9:12 AM -0400 4/9/14, Phillip Hallam-Baker wrote:
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.
To me it sounds like a knee-jerk reaction rather than an assessment of what
we need to protect and what the costs are of various mechanisms.
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.
We actually have a few more email security standards, but regardless, I
don't think the major barrier to deployment is that there is not a single
standard. There are a number of reasons why email end-to-end encryption is
rarely used, which include the difficulty of managing keys, but it's also
worth pointing out that end-to-end encrypted email breaks a lot of the
anti-spam, unless users share their private keys with their mail provider
(which kind of defeats the point).
As a meta-point, people can disagree with me over whether I have
solved all the problems but I am pretty sure that I already know most
if not all the problems that people come up with after thinking about
the problem for a few minutes. I have been discussing this for quite a
while now and I used to sell S/MIME as a main product for about ten
years. I have discussed the problem with Callas and Zimmerman.
Too much security is a really easy problem to solve: allow people to use less.
There are many reasons why end-to-end is not the only model that a
message layer encryption system should provide. It actually doesn't
break as much anti-spam as is imagined. Content-analysis is not a
powerful anti-spam technique. But there are some situations in which
archiving is required for regulatory reasons.
The end-to-end model should be an option, not a requirement.
I am very comfortable with a model in which 95% of my mail is
encrypted to a key held by my mail provider and the 5% that I consider
to be sensitive is secured under an end-to-end key only I hold and
mail is only accepted under that key from pre-approved senders.
I go into a very full requirements analysis for making secure email work here:
http://www.youtube.com/watch?v=06KyOCtjxLs
The end-to-end model is really not a useful one for security
discussions because the ends of the IP channel are not the same as the
ends of the conversation. The important part is being able to know
where the end-points are so that senders can make a decision on that
basis.
S/MIME and PGP don't actually enforce an end-to-end model. But because
they assume that is all that is wanted they make end-to-end an all or
nothing proposition.
Since my security concerns are a little different to most I would
probably end up with a three tier model in which mail from people I
don't know goes to the Gmail/Postini decryption key, most mail from
most people I have whitelisted goes to a decryption key that is on all
my machines I configure for mail and I also have a key for sensitive
stuff that is only on one or two machines or is in a smart token.
I can make the two tier scheme transparent from a usability point of
view but when we get into three or more tiers it starts to demand more
of users which is why I would not make it default.
--
Website: http://hallambaker.com/