Re: Security for various IETF services

Phillip Hallam-Baker <> Thu, 10 April 2014 11:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A45FC1A0158 for <>; Thu, 10 Apr 2014 04:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Df_eEpFhdi6N for <>; Thu, 10 Apr 2014 04:51:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::235]) by (Postfix) with ESMTP id DC7D91A0212 for <>; Thu, 10 Apr 2014 04:51:51 -0700 (PDT)
Received: by with SMTP id c11so2171077lbj.40 for <>; Thu, 10 Apr 2014 04:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1NA+joCUYRJlh8WDjtkDnHAKBB9oB6ukJwNfBKCyX1M=; b=SlWZuKoUn97t5j30hos4lEp3TzAdj/x4BiV/icrrqZQxScdLYOh2NFDWau8TtVC2fE M5oMj1ahyvoNHn0vgKMmOdL9FKHTnRHAosazKghQ4Rtf1C7hc/kxpunIJh30rMNHPM9s BTUcAEWXsg3J3zC1w9AbtVDVVSYC0lkBr3kxZ6iZuPNZCshylObkwXKkFbDNbMozC9Km rTz0GtfvLIkKpIO9Q+d9aRaJDXlsLFSDDQ4qCcFSvkBJCJP/fQ7Xe61zGjV3rcn8L4p3 S2zoYDmpOqZKOTWICo46w0mDyEO+nIz6ymiUrI8aGOv8759e6ucszDX3KnoRdpaARqu3 hgWQ==
MIME-Version: 1.0
X-Received: by with SMTP id am9mr12104337lac.15.1397130710421; Thu, 10 Apr 2014 04:51:50 -0700 (PDT)
Received: by with HTTP; Thu, 10 Apr 2014 04:51:50 -0700 (PDT)
In-Reply-To: <p06240604cf6baa6b989d@>
References: <> <> <p06240601cf639cb2113b@> <> <> <p06240604cf6baa6b989d@>
Date: Thu, 10 Apr 2014 07:51:50 -0400
Message-ID: <>
Subject: Re: Security for various IETF services
From: Phillip Hallam-Baker <>
To: Randall Gellens <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Apr 2014 11:51:57 -0000

On Wed, Apr 9, 2014 at 10:01 PM, Randall Gellens <> 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:

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

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.