Re: [openpgp] The DANE draft

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 24 July 2015 12:39 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 87C691A026A for <openpgp@ietfa.amsl.com>; Fri, 24 Jul 2015 05:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 DyeSOR7AMvhh for <openpgp@ietfa.amsl.com>; Fri, 24 Jul 2015 05:39:13 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25D51A0235 for <openpgp@ietf.org>; Fri, 24 Jul 2015 05:39:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5EE3BE9A; Fri, 24 Jul 2015 13:39:10 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHEutJ01oFuj; Fri, 24 Jul 2015 13:39:09 +0100 (IST)
Received: from [31.133.179.222] (dhcp-b3de.meeting.ietf.org [31.133.179.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D33CBBE49; Fri, 24 Jul 2015 13:39:08 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437741549; bh=Xjr3tGO3TB3WCt8Evve4nJsNIT7VuWVzJEszlO/ct4g=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OumI0Iw1g3JaHskoeFhAzQObYgnLtUeJV+QRUi/D2/gcWJgpEs31A9zhlkMGLgGeu o627ZalsEigfclTIzAk96h8i5yJj4QyoYm1NY+kUQqM/XBO1KXUIGkE5bNcCiRHanP MJz+R8XslxeQ/mDtozBTSdWIt25nBoAS27++pc18=
Message-ID: <55B231EB.6000703@cs.tcd.ie>
Date: Fri, 24 Jul 2015 13:39:07 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <phill@hallambaker.com>, IETF OpenPGP <openpgp@ietf.org>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com>
In-Reply-To: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/2Awyr-7XiQnk785ud_xqk2lTXBg>
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: Fri, 24 Jul 2015 12:39:15 -0000


On 24/07/15 11:40, Phillip Hallam-Baker wrote:
> To clarify the point I was attempting to make at the mic.

Sure. I'll do the same(ish:-)

The draft in question is [1] and has been a work item for
the DANE WG for a year or so.

Please do read and comment on the draft - if there are PGP
things in there that need fixing we should get those fixed.
Such comments for now are best sent to dane@ietf.org.

If you want to comment on the charter of the DANE WG please
do so on ietf@ietf.org (or chat with me). Just as with this
WG, the DANE charter was subject to IETF last call already.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-dane-openpgpkey

> 
> 1) The draft is approaching IETF last call. People working on OpenPGP
> should review it now.
> 
> 2) If people find it does not meet OpenPGP needs, they should say so and
> have no qualms about objecting. It is much more important that there be a
> spec people use than that the document progress quickly.
> 
> If people want their drafts to progress quickly they should do that by
> getting buy in from the community they purport to be serving.
> 
> 3) It is quite possible that it is better that there be no DANE for PGP RFC
> either at this stage or ever.
> 
> 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. This was a task that really demanded a
> high level of systems thinking if it is going to succeed. All such advice
> was rejected.
> 
> People have been attempting to put email address related records into the
> DNS since the first drafts of the spec and none has taken off.
> 
> It might well be that the best way to take advantage of the opportunities
> DNSSEC affords would be to make changes at the OpenPGP end rather than the
> DNS end.
> 
> I remain convinced that the interface between a DNS based PKI and any other
> PKI should be approached as a cross-certification type activity and the
> hand over between DNSSEC and whatever other PKI is to be used should be a
> single 'certificate' (or key signing or whatever you want to call it).
> 
> So the way that I would approach using DNSSEC to validate a key for '
> alice@example.com' would be to introduce a record in the DNS with the
> semantics 'X is authorized to sign for *@example.com'. I would not attempt
> to fill the DNS with keys for Alice, Billybob, Carol, Doug, Ethelred and
> co. It is not working for TLS and I don't think it will work for OpenPGP or
> S/MIME.
> 
> 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. The DNS
> has no persistence to it. Give me the MIT keyserver any day.
> 
> 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.
> 
> 
> The above might sound a bit handwavy because it is. But I can demonstrate
> the claims mathematically in terms of work factor. If the work factor for
> introducing a bogus key is $100 at time t and we intern the key (and chain)
> in a blockchain at time t, then the work factor becomes > $GDP(USA) after
> time t.
> 
> 
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp
>