Re: Security for various IETF services

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 10 April 2014 11:57 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF01A0167 for <ietf@ietfa.amsl.com>; Thu, 10 Apr 2014 04:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_PWOXN1dAmD for <ietf@ietfa.amsl.com>; Thu, 10 Apr 2014 04:57:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4501A1A016C for <ietf@ietf.org>; Thu, 10 Apr 2014 04:57:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81572BEB0; Thu, 10 Apr 2014 12:57:40 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NHn4d7fQ99R; Thu, 10 Apr 2014 12:57:40 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 58079BEA0; Thu, 10 Apr 2014 12:57:40 +0100 (IST)
Message-ID: <53468734.4060809@cs.tcd.ie>
Date: Thu, 10 Apr 2014 12:57:40 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <hallam@gmail.com>, Randall Gellens <randy@qti.qualcomm.com>
Subject: Re: Security for various IETF services
References: <533D8A90.60309@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E779EEB6@EXMB01CMS.surrey.ac.uk> <p06240601cf639cb2113b@99.111.97.136> <F8AEEDAE-C8BB-4979-8122-1110DFF62770@cisco.com> <CAMm+LwgLxR65a1nKmKpqW39_BvgMgAGwBCxAE+eEs-9bnLdv8A@mail.gmail.com> <p06240604cf6baa6b989d@99.111.97.136> <CAMm+LwhxHi2Wj=L3sCPQgHna=SrQr4rbfh7B8vYfQdoLJUqkng@mail.gmail.com>
In-Reply-To: <CAMm+LwhxHi2Wj=L3sCPQgHna=SrQr4rbfh7B8vYfQdoLJUqkng@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/szpyN0HZuWLfP6FxJaD81jmKOr0
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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.

Thanks,
S.

On 04/10/2014 12:51 PM, Phillip Hallam-Baker wrote:
> On Wed, Apr 9, 2014 at 10:01 PM, Randall Gellens <randy@qti.qualcomm.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.
>