Re: Security for various IETF services

Phillip Hallam-Baker <hallam@gmail.com> Wed, 09 April 2014 16:37 UTC

Return-Path: <hallam@gmail.com>
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 C95A41A02F7 for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 09:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uds7gYotXKT9 for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 09:37:22 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5452A1A0380 for <ietf@ietf.org>; Wed, 9 Apr 2014 09:37:22 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id c11so1372292lbj.12 for <ietf@ietf.org>; Wed, 09 Apr 2014 09:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dz6u4Ltj5JiQRYse3gPc5qy8a8RlaGSH6Yu1T6hYKZM=; b=nRE9WyOxlTnq+BWuK69f26NNpiPD54MOSEIRJAeV+sw6tr+81gI8wZ0i06fMstdiVg znt61ya2NSo5v2svYBW8UAhxGmcX/Rwa73ebznXhuDgt98+/RupSlXi0ehyrDOzvmaWT osDOBS2o3LgY9mt9/DAOwhTggZcPRww5Y09lp/w+Bq1W57q0ASF4qIRnm5R7d5W9ovDY MuxPFYoQ8XxuaRR3QuYgqdacEeyCJCMBl4ik+6ZaB8gzSOGFbTyYrIG9DJpEwkPFAeKr mgqEVnhKXJyFvPsPj2ZJKHKBYLILsaw51yx4pJ5ayhkwh8eW4YgHZ8z5zVahv4gLfMS9 asRA==
MIME-Version: 1.0
X-Received: by 10.152.19.65 with SMTP id c1mr2996077lae.35.1397061440853; Wed, 09 Apr 2014 09:37:20 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Wed, 9 Apr 2014 09:37:20 -0700 (PDT)
In-Reply-To: <20140409154919.11E6118C106@mercury.lcs.mit.edu>
References: <20140409154919.11E6118C106@mercury.lcs.mit.edu>
Date: Wed, 9 Apr 2014 12:37:20 -0400
Message-ID: <CAMm+LwhVm68yvbi4RYqAbQvbQs_7vZ8JF3e38UYH_RCoEv0sVg@mail.gmail.com>
Subject: Re: Security for various IETF services
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/NOdamdWNmxHWPMSQmUsEDlGnyk4
Cc: IETF Discussion Mailing List <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: Wed, 09 Apr 2014 16:37:28 -0000

On Wed, Apr 9, 2014 at 11:49 AM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>     > From: Phillip Hallam-Baker <hallam@gmail.com>
>
>     > a security standard must have no impact at all or it won't be used.
>
> While I agree with the conclusion part ("or .. used"), isn't the first part
> sort of internally contradictory? Adding security almost always has some
> cost, in that people have to set up the security, etc. (I'm thinking in very
> broad terms here - e.g one has to lock one's car/house, enter a security code
> to use an ATM card, etc, etc.) OK, so HTTPS has basically zero impact on the
> average user - is the same level of user inattention really possible with
> email security?

What I currently have is a prototype that makes sending the email
completely transparent except in the case where I either want to only
send the mail if t can be sent encrypted or only if it can be sent
encrypted under particular security guarantees.

That bit is almost complete, I just need to finish one little bit and
its good to go. It works with the mail client you have right now
without any plug in or extension. The outbound mail is redirected
through a proxy which does all the necessary.


The second part is the configuration model. Right now the situation is
that configuration is a one time operation. But it is far from
painless because I am using the legacy clients and the configuration
model is, well stupid. It requires a lot of user intervention and
understanding.

I have a plan that will make that part easier than configuring a mail
client today. i can't make configuring crypto a zero effort operation
but I can make sure you only need to do it once per device (i.e.
subsequent updates are completely automatic). And I can make the joint
task of configuring the crypto and the mail account settings easier
than one or the other alone.

This is the part that I am coding now. It does have impact on the use
piece however since one of the ways I am simplifying the approach is
to have as much consistency as possible. Rather than deal with a
single key or dual keys for encryption and signature I require
everyone have dual keys. This makes it much easier to do recovery from
user blunders or machine failures.


-- 
Website: http://hallambaker.com/