Re: [openpgp] The DANE draft

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 25 July 2015 16:25 UTC

Return-Path: <hallam@gmail.com>
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 525891A87CB for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 09:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5zKWZCK1AfPI for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 09:25:34 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011461A88C5 for <openpgp@ietf.org>; Sat, 25 Jul 2015 09:25:34 -0700 (PDT)
Received: by lbbzr7 with SMTP id zr7so30943867lbb.1 for <openpgp@ietf.org>; Sat, 25 Jul 2015 09:25:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ev7EcCN1QB/O49GbHhDagCAe6T/PML+EcQQlNYt3jCI=; b=vQP4mq5ZoN0TE6/fwAcqp4kaszjVmJGEWWawmpJFSayCjuqhtH4MnKPd8oAdF0JMW9 qzSxMvKbeWBmkoTKvgDztMbNY5JRcWwH6ZE3fPx7xwpEyHAbA/tR9YOB2Dg4TARjEpRB js9hDBk20DBVrUOHYsUNzIU8bme7Q/Hq2THbUrDwZ1hqIVUi/qJK4Nyf88Al0p/AunYx bY19diyqZIBU3U6nI1sujl+HA5ue2/KuIjMvTUryJVHbLR86notuZxPDbRPBEvXOGhna lAWO1/E3n37ga0NOPWi55k8HloJXjIP07hvR4+SEiaw3jTc0R4UT2zBSUOs4XqbhmVxV q5gw==
MIME-Version: 1.0
X-Received: by 10.112.185.100 with SMTP id fb4mr19191572lbc.79.1437841532583; Sat, 25 Jul 2015 09:25:32 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Sat, 25 Jul 2015 09:25:32 -0700 (PDT)
In-Reply-To: <alpine.LFD.2.11.1507250832510.854@bofh.nohats.ca>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com> <87bnf1hair.fsf@alice.fifthhorseman.net> <alpine.LFD.2.11.1507250832510.854@bofh.nohats.ca>
Date: Sat, 25 Jul 2015 12:25:32 -0400
X-Google-Sender-Auth: 7kS_d4fTdFukNrxzlBm6HqDMzTY
Message-ID: <CAMm+LwhtQfUdsd0Tt8P7iLy+4UN6Sznp89emVQFt5bJeiEYAwg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="001a11c3ca22cb0383051bb591a9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/QVU60O2Qiqzcys7EoVAHVYtnbF4>
Cc: IETF OpenPGP <openpgp@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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 16:25:35 -0000

On Sat, Jul 25, 2015 at 8:56 AM, Paul Wouters <paul@nohats.ca> wrote:

>
> 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.
>

Again, you don't seem to understand the spec. 'MUST USE TLS' is one of the
purported benefits. Key pinning to a specific key is another. Those are
security policy.

I think those should be taken out of DANE but that hasn't happened yet as
far as I am aware.