Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey

John C Klensin <john-ietf@jck.com> Tue, 22 September 2015 14:12 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F01A884E; Tue, 22 Sep 2015 07:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 WbCDX0-1Q-xe; Tue, 22 Sep 2015 07:12:21 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907291A884D; Tue, 22 Sep 2015 07:12:21 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZeOIt-000Mum-2z; Tue, 22 Sep 2015 10:12:19 -0400
Date: Tue, 22 Sep 2015 10:12:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Paul Wouters <paul@nohats.ca>, ietf@ietf.org
Message-ID: <754374D2DB528FC99BE470A8@JcK-HP8200.jck.com>
In-Reply-To: <alpine.LFD.2.20.1509211455150.420@bofh.nohats.ca>
References: <20150921172109.19893.qmail@ary.lan> <alpine.LFD.2.20.1509211455150.420@bofh.nohats.ca>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/79BHgKYeZU0ASUqB-B4vl_c8F1g>
Cc: dane WG list <dane@ietf.org>
Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2015 14:12:23 -0000


--On Monday, September 21, 2015 15:14 -0400 Paul Wouters
<paul@nohats.ca> wrote:

>> Sure, but it's the way that everyone has used PGP for 20
>> years, and it's the security model that everyone I know
>> expects when they use PGP keys.
> 
> Actually, nmost people I know never use the WoT. They only use
> keys
> obtained directly from the person they want to exchange
> encrypted email with.

Paul,

I have no doubt that is true, but I think it has a lot to do
with Harald's comments about tools and George's comments about
models.  First, I know a lot of people who insist on keys who
are handed to them directly (or mailed with in-person or other
out of band transfer and verification of fingerprints).  I know
almost as many who almost exclusively pull things off
keyservers.  Especially with those tools that will not allow
using a key unless if bears one's personal signature (even if
non-exportable), all of those keys are incorporated into that
individual's WOT, even if the key is a self-signed one obtained
from a keyserver that no person who understood the issues and
was sane would rely upon.   Consequently, "never use the WOT"
either involves a different definition than I've used or I don't
understand what it means.    

Whether those "who to trust and why" decisions are wise or not
is another matter (and I think closer to George's concerns).

However, if you believe that, because of trust issues, people
get keys only from personal contacts rather than indirectly from
public databases, why are we discussing yet another public
database-based approach?   Or are you convinced that the problem
with the other public databases is that the DNS is inherently
better for some reason such as the inability of third parties
not associated with the domain in the address to add keys?  Or
that the DNS is somehow, inherently, the One True Database to
Rule Them All for the Internet?   (That is, of course, another
variation of my desire that the next version of the document be
much more clear about the problem(s) it is trying to solve.)

    john