Re: [Endymail] Another view of the problem and what the IETF could do

Leo Vegoda <leo@vegoda.org> Tue, 02 September 2014 19:47 UTC

Return-Path: <leo@vegoda.org>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35161A887F for <endymail@ietfa.amsl.com>; Tue, 2 Sep 2014 12:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 H4Ly_9Nu2k_r for <endymail@ietfa.amsl.com>; Tue, 2 Sep 2014 12:47:13 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04871A8862 for <endymail@ietf.org>; Tue, 2 Sep 2014 12:47:12 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id k14so7298144wgh.28 for <endymail@ietf.org>; Tue, 02 Sep 2014 12:47:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=5eHXqEQEBdAi02WN7fQLh0XqL1vUPD2rKXyChcZn5Fo=; b=DtuHPGM8TMNhO1OfXhFlornzyYs+1T7ANs7LMsZCjI+4LvpyMSk3GWm/nExxtvWx16 TcoV38Lm7kTSwfVvypJ1rpQynldv/+3m0LVhqlGlCKc1wMQJLhTgRxOwKKmhI4dwfSg1 SkGNchLa53B4XmWwLXILIBOZ+x4zoKA1jfoDPmcYuPYvc0eXvlz0OHpYUBLzJpr/JEiu Kyz8Kuxz57Sgf47vL1w8SRhV1bKg6Kp8ETZfXK2k4nhJ4jdkj7OynPTYhQon1sYKdMz4 9v/z2qj2SBrt6TRdMmfU2zRukX1X0jcnkAHyB0tJSR1cSMO9ppYnd+IgJsUCtibE31tc J4MQ==
X-Gm-Message-State: ALoCoQmnUKuuGkYCUvvUy6wwm6ZTI5vEs3/etF3iB8aib+jieIdhIuB8V7IC/Df9LAeGEy0bt+Ly
X-Received: by 10.194.60.240 with SMTP id k16mr4966829wjr.109.1409687231467; Tue, 02 Sep 2014 12:47:11 -0700 (PDT)
Received: from vegoda.org (v6only.vegoda.org. [2a00:1098:0:86:1000:26:0:1]) by mx.google.com with ESMTPSA id h6sm11495149wjb.33.2014.09.02.12.47.09 for <multiple recipients> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Sep 2014 12:47:10 -0700 (PDT)
Date: Tue, 2 Sep 2014 20:47:06 +0100
From: Leo Vegoda <leo@vegoda.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20140902194706.GC8044@vegoda.org>
References: <CAHBU6iuxfqs9RszSaJLaTV_obKBCJ9Pzii+t9XANN3q+bJm-3Q@mail.gmail.com> <878um3prio.fsf@vigenere.g10code.de> <cddbc815-a98a-48e5-8dea-c3d8a68ca4d9@gulbrandsen.priv.no> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5405EEB8.1060107@cs.tcd.ie>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/CvMJEhuwxrtSpmCE0S4hJ8lmGE8
Cc: Werner Koch <wk@gnupg.org>, Steffen Nurpmeso <sdaoden@yandex.com>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, endymail@ietf.org
Subject: Re: [Endymail] Another view of the problem and what the IETF could do
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Sep 2014 19:47:18 -0000

On Tue, Sep 02, 2014 at 05:22:16PM +0100, Stephen Farrell wrote:
> 
> I'm not quite sure I'm reading this correctly, but just in
> case...
> 
> On 02/09/14 17:02, Leo Vegoda wrote:
> > Handing out cryptographic identity certificates or similar to people
> > who do not understand the risks or benefits and do not have a
> > suitable key management framework doesn't seem a great idea to me.
> 
> If this list concludes that an Internet-scale key management
> framework is required where all key holders are strongly
> authenticated before they get any functional benefit, then
> that makes life easy - we have 20+ years of evidence that
> there's no point in bothering to try construct that;-)

That's not quite what I meant. What I meant is that if there is an
authority handing out certificates then it should do so in a
responsible way. Cryptographic certificates are sufficiently
different from photographic identity documents that pre-existing
assumptions need to be changed to avoid disappointment.

This does not need to be hierarchical but it does need some
infrastructure support and either some really outstandingly good
user interface design or education. If users receive encrypted
e-mail and then loose the corresponding private key then they loose
the ability to read old messages. People working for organizations
handing out X.509 certificates for S/MIME use get training and their
keys might well be escrowed. But ordinary individuals are unlikely
to get training and they do expect to be able to read old e-mails. 

I think this is the sort of basic usability issue that requires some
kind of user friendly key management. Whether it needs to be
Internet-scale - well I don't know - but it needs to be good enough
that the key is reasonably secure if a laptop or tablet is lost or
stolen. 

I expect that in most cases strong authentication is not required
but people will need some kind of mechanism for evaluating how much
trust to assign a new key they have not seen before and that will
also require some kind of education or another superb user
interface. Most people will be new to cryptography and will need
some help.

Leo