Re: Security for various IETF services

Stephen Farrell <> Thu, 10 April 2014 11:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DFEF01A0167 for <>; Thu, 10 Apr 2014 04:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W_PWOXN1dAmD for <>; Thu, 10 Apr 2014 04:57:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4501A1A016C for <>; Thu, 10 Apr 2014 04:57:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81572BEB0; Thu, 10 Apr 2014 12:57:40 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0NHn4d7fQ99R; Thu, 10 Apr 2014 12:57:40 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 58079BEA0; Thu, 10 Apr 2014 12:57:40 +0100 (IST)
Message-ID: <>
Date: Thu, 10 Apr 2014 12:57:40 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>, Randall Gellens <>
Subject: Re: Security for various IETF services
References: <> <> <p06240601cf639cb2113b@> <> <> <p06240604cf6baa6b989d@> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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:57:45 -0000

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.


On 04/10/2014 12:51 PM, Phillip Hallam-Baker wrote:
> 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
> 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.