Re: Agenda, security, and monitoring

On Mon, Feb 3, 2014 at 9:05 AM, Theodore Ts'o <tytso(_at_)mit(_dot_)edu> wrote:

> On Sun, Feb 02, 2014 at 06:44:58PM -0600, Pete Resnick wrote:
> > I agree that authentication is irrelevant in this context. But
> > that's leads me to agree with Dave on a central point (hence the
> > little I-D we've been banging on and submitted to the STRINT folks):
> > The problem with PGP and S/MIME is that they require authentication
> > in order to start using encryption, and since authentication is both
> > irrelevant to this *and* a pain to do...
> We should be a bit careful about our terms here.  If we don't care
> about authentication at all, one solution is to just do hop-by-hop
> diffie hellman (or TLS with completely unchecked certificates).

Yes, we need to decide what the threat model is and what the outcomes we
want to achieve are.

We also have to consider if there really are are downsides to having people
use less than perfect encryption. Because a lot of the reason for email
encryption taking so long seems to me to be people worried about doing it
wrong and making a mess. And that is the reason that PGP exists in the
first place: Phil Z. got tired of waiting for perfect and decided that
'Pretty Good' would be enough.


I see two separate sets of reasons for getting the whole IETF to start
doing secure email

1) We need to get people to start eating the dog food so that they
understand the reasons why the customers still refuse to eat it after 20
years.

2) Everyone who is involved in IETF in a significant degree is a target.
Intelligence services go after people who have the information they want.
And we have more of that than most. And its not just the security area
either. The pervasive intercept capability folks must keep a close eye on
technical changes that would affect their capabilities.


For twenty years now we have been arguing over PGP vs S/MIME. Lets stop
that. Both specifications could do with an upgrade. Lets develop an upgrade
that is a worthy successor to both and provides for full backwards
compatibility or as much backwards compatibility as makes sense for both.
-- 
Website: http://hallambaker.com/