Re: [openpgp] The DANE draft

Paul Wouters <paul@nohats.ca> Sat, 25 July 2015 12:56 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C71A9147 for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 05:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 1ImPBxrxbNnN for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 05:56:22 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CA61B2DF6 for <openpgp@ietf.org>; Sat, 25 Jul 2015 05:56:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mdnT93PdnzD7S; Sat, 25 Jul 2015 14:56:13 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=P1uZcWOp
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bu3yM6g_Of6g; Sat, 25 Jul 2015 14:56:11 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 25 Jul 2015 14:56:11 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2D17180042; Sat, 25 Jul 2015 08:56:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437828970; bh=vmHGKQJ6x+IyTwZEzeFUGhHi9QADjNGhVUHSFp4Q5VU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=P1uZcWOpiBWTn2XOuZtEaOQUQ/APKszRLVwMoXfSujGns+XW9/bB5juRcG8LR2V4B QWQbl2qyJHw78+k64hGfCAlon7l3CPvT2IMTCiFDSudXG7TK7ooJN2JARxfz3wUAZg i6GGE03l5ULyTTEm+2lTX/SAeP3lppthRshvF6Mo=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6PCu9Cr014247; Sat, 25 Jul 2015 08:56:09 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sat, 25 Jul 2015 08:56:09 -0400
From: Paul Wouters <paul@nohats.ca>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In-Reply-To: <87bnf1hair.fsf@alice.fifthhorseman.net>
Message-ID: <alpine.LFD.2.11.1507250832510.854@bofh.nohats.ca>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com> <87bnf1hair.fsf@alice.fifthhorseman.net>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/9khEwdCKRdCHHlL6hmkjC0FSBoA>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] The DANE draft
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jul 2015 12:56:24 -0000

Answering phb and dkg:


> I looked at it with Petr Spacek after the meeting, and i plan on
> providing Paul with a more detailed review shortly.

Greatly appreciated!

>> DANE is trying to do three different things. It is trying to be a key
>> discovery service, a security policy publication mechanism and a way
>> of validating keys using the DNSSEC.
>
> I think this overview is accurate.

That's not how I see it. It is surely a discovery and distribution
system for keys. But it is not a policy publication mechanism.  The
draft (carefully) does not tell you what you can or cannot do with the
key. Some people tried to propose this (mostly for smime) by having
different prefixes for _encrypt or _sign, but this was not adopted.

Of course, one can deduce policy. If you get the key
fedora22@fedoraproject.org from DNS you could expect that is the key
which we use to sign our packages. But that's not different from grabbing
a key from a random key server and assuming you can use it for email. the
assumption of what to do with the key really lies in the ID/email address
used for the key. So I do not think the openpgpkey draft changes that.

>> I do not find the idea of relying on the DNS for my keys remotely
>> comforting and would not want to rely on such a record directly.

You dont have to rely only on DNSSEC. You grab the key from DNS, and
then you can go out to other places (keyservers, your personal pubring,
etc) to attempt to gain enough trust in the key for your personal taste.

>> The DNS
>> has no persistence to it. Give me the MIT keyserver any day.

Let me generate another 1000 phb keys and upload those to the MIT
keyserver. What DNS does provide is that you don't have to look through
the chaf to find the wheat. You cannot add a bogus key for
paul@nohats.ca into my DNSSEC zone. And importantly, if you control
part of my network, you cannot confuse me into believing there is no
such key published for paul@nohat.ca. Compare this to the MIT key server
that accepts requests on port 80 and can easilly be MITM'ed to filter
results.

>> What would interest me is if I could take a DNSSEC trust chain and intern
>> it in a blockchain. At that point the whole process becomes transparent and
>> I have a key I can place quite a bit of reliance on.

So turn your pubring.pgp into a blockchain? I don't see why it matters
that the keyblob came from MIT or DNSSEC. In fact, I can also argue
that the keyservers are worse because there is no sign that the key is
still actively supported/known by its user, while the fact that the key
is still in DNSSEC (or no longer in DNSSEC) gives me additional
information to make a decision on whether or not to use the key or
postpone my email until I know more.

> It sounds to me like you're interested in DNSSEC Transparency.  Perhaps
> you could take that up in the trans WG?  I know there are other people
> interested there (i am!) but this discussion doesn't belong on the
> OpenPGP mailing list.

Agreed [*]

Paul
[*] speaking without my trans co-chair hat