Re: What real users think [was: Re: pgp signing in van]

Dave Crocker <dhc@dcrocker.net> Mon, 09 September 2013 20:36 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A7121E80D9 for <ietf@ietfa.amsl.com>; Mon, 9 Sep 2013 13:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2TPZy74gM1i for <ietf@ietfa.amsl.com>; Mon, 9 Sep 2013 13:36:48 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD8A21E80C6 for <ietf@ietf.org>; Mon, 9 Sep 2013 13:36:46 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r89Kaf1a001335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Sep 2013 13:36:45 -0700
Message-ID: <522E3141.5060609@dcrocker.net>
Date: Mon, 09 Sep 2013 13:36:17 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Steve Crocker <steve@shinkuro.com>
Subject: Re: What real users think [was: Re: pgp signing in van]
References: <m2zjrq22wp.wl%randy@psg.com> <2309.1378487864@sandelman.ca> <522A5A45.7020208@isi.edu> <CA2A6416-7168-480A-8CE1-FB1EB6290C77@nominum.com> <522A71A5.6030808@gmail.com> <6DE840CA-2F3D-4AE5-B86A-90B39E07A35F@nominum.com> <CAPv4CP_ySqyEa57jUocVxX6M6DYef=DDdoB+XwmDMt5F9eGn1A@mail.gmail.com> <18992.1378676025@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B63077527BC7A@mbx-01.win.nominum.com> <13787.1378730617@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B63077527C8AB@mbx-01.win.nominum.com> <522E2AE4.6010908@gmail.com> <522E2C78.4050706@dcrocker.net> <F17097BC-AAD6-48EA-80D3-202DC45F7C70@shinkuro.com>
In-Reply-To: <F17097BC-AAD6-48EA-80D3-202DC45F7C70@shinkuro.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Sep 2013 13:36:45 -0700 (PDT)
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Mon, 09 Sep 2013 20:36:55 -0000

On 9/9/2013 1:27 PM, Steve Crocker wrote:
> Actually, I interpret the chemistry professor's comment in a
> different light.  It would be possible to design a system where:
>
> o the standard end user software doesn't facilitate editing the other
> person's text, and
>
> o each piece of text is signed.
>
> The result would be a system where a recipient would know whether the
> person who is alleged to have written a piece of the message actually
> did so, and the normal mode of use would be to leave things
> untouched.  Or, if you edit someone else's text, it immediately
> becomes your text.


The professor's comment was on function, not method. My comment was on
the limitations to methods available at the time.

In a controlled environment, with good resources, quite a bit is
possible. Indeed, server-based "department-level" email products in the
1980s did enforce such restrictions. The single-administration servers
had complete control over the message.

Distribution with independent administrative authorities makes this a
very different game. Enforcement by fiat is impossible.

That's where signing comes in, of course. Modify the content and the
signature fails. Besides the computational overhead -- which was
relatively onerous back when the infrastructure was being established --
this requires that the receiver know and demand that the signature be
present; this requirement has its own adoption barriers.

Starting with a blank sheet and today's technologies, the requirement is
possibly feasible to satisfy -- if we ignore the continuing human
factors barriers to large scale email authentication. However given the
resources at the time the operational service was developed, I think it
wasn't.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net