Re: Security for various IETF services

[Stephen Farrell <[e-mail]>]

Just to note that this has wandered off topic, but is a
fine separate topic. Could be better on saag maybe but
please change the subject if continuing here.

Reason this is a different topic: this is about a new
protocol and is not something that'd be covered by the
proposed iesg statement until much later after it'd
worked out well.

Thanks,
S.

On 04/10/2014 12:51 PM, Phillip Hallam-Baker wrote:
> On Wed, Apr 9, 2014 at 10:01 PM, Randall Gellens <[e-mail]> 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.
>