Re: [openpgp] The DANE draft

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 25 July 2015 16:45 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 47E1C1A8799 for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 09:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 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, J_CHICKENPOX_34=0.6, 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 cp94ENReG9Vj for <openpgp@ietfa.amsl.com>; Sat, 25 Jul 2015 09:45:04 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 625B61ACE04 for <openpgp@ietf.org>; Sat, 25 Jul 2015 09:45:03 -0700 (PDT)
Received: by lbbzr7 with SMTP id zr7so31082391lbb.1 for <openpgp@ietf.org>; Sat, 25 Jul 2015 09:45:01 -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=+VfX5mOC9keOZlGNErY/12k2fvzlYoPeHQbn+p19Etg=; b=Ju+PkIaRmG2LOLOZhIMHjwJDq7s7XLjEfyJk6jBpswp1jLQopc8phomM9ZAhYI8Mnh r4Ei1K8r6fjruGNfT4ktsUiwqm1rMV85WrFLSrOYke1IHLjpcZMCgw0b6dwn5BaNH9rl VsG1J5m/ROWDP+ZJWDEfIQPEw9us05ZEzarDKE4f/ZGvvi6QW630hZ8cfu+SwWK0tTOz 5Ewv+0gauyo185DEMrRZGxSWeG23+8W/IMLYMBhxJMq7S/1baF44+uOqewRb98indHA4 qtWGGkPDf0Ij22atN4B6W4jIN5WqRO/av2tKAY6/F4teK3g6lprlYTQaCGfmQhDX7Ni1 5tEg==
MIME-Version: 1.0
X-Received: by 10.112.123.179 with SMTP id mb19mr19513676lbb.55.1437842701716; Sat, 25 Jul 2015 09:45:01 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Sat, 25 Jul 2015 09:45:01 -0700 (PDT)
In-Reply-To: <87bnf1hair.fsf@alice.fifthhorseman.net>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com> <87bnf1hair.fsf@alice.fifthhorseman.net>
Date: Sat, 25 Jul 2015 12:45:01 -0400
X-Google-Sender-Auth: EX-eH2FuraG3LopILTchTzpLSyI
Message-ID: <CAMm+LwhGCtoNrLcDKA8PDDSM5DJN50G1Y+6V99v1hB9eyzjkgw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: multipart/alternative; boundary="047d7bfd04767a9290051bb5d7e8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/1FMuigBx1GPulK7Z1NTHgGbPTrg>
Cc: 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 16:45:06 -0000

On Fri, Jul 24, 2015 at 10:53 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net
> wrote:

> On Fri 2015-07-24 12:40:31 +0200, Phillip Hallam-Baker wrote:
> > 1) The draft is approaching IETF last call. People working on OpenPGP
> > should review it now.
>
> I looked at it with Petr Spacek after the meeting, and i plan on
> providing Paul with a more detailed review shortly.
>
> > 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.  I also think all these things are
> necessary.  While i'm not particularly excited at the prospect of a
> hierarchically controlled system like DNS being the One True System, we
> do need to find ways to address these three goals anyway.


Agreed. But OpenPGP already has a fairly effective key distribution
infrastructure. As a rough guide:

The CryptoMesh = OpenPGP Key Servers + Certificate Transparency - Cruft
         + Marketting bullcrap.

I am happy to leverage the DNS as one way to validate keys but it can't be
the only way. And the way it is designed means it isn't actually a
particularly convenient one.

And don't underestimate the value of marketing bullcrap. Before the Web,
people had been trying to make network hypertext work for decades.



> > 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 think you mean "X is authorized to certify any key+User ID where the
> user ID matches *.example.com", not that X is allowed to make sign mail
> for *@example.com.  right?


Yes, every end entity should have their own key. But if all you do is
domain validation then the domain owner is alway going to be able to sign
for alice@example.com by publishing a key.

I don't think that is a big problem because I don't think you can expect
digital signatures to be legally non-repudiable without some additional
infrastructure to validate the key holder in the real world. Like an
in-person notary verification at minimum.



> I like this idea as a way of validating keys
> for the DNSSEC (the third of your three prongs of DANE).  If you were to
> make a record with the semantics "any OpenPGP key+User ID where the User
> ID matches *@example.com should not be considered valid *unless* it is
> certified by this key", then you could use it as a security policy
> mechanism (prong two).


There might be a requirement for that type of record. It is in effect a
cryptographically enforced variant of CAA. But stopping unauthorized use of
OpenPGP is not top of my priority list right now.



> > 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.
>
> So it sounds like the part you disagree with is the use of DNS/DANE as a
> key discovery service (prong one).


Yes, the key servers work. They are deployed. The only reason to replace
them would be with something better.


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

Yes, I have written a TRANS notary (besides the one Rob wrote). I know the
spec. But that is an infrastructure targeted at a single task and working
within a set of rather obnoxious constraints (PKIX).

Right now, that discussion certainly does not belong in TRANS any more than
OpenPGP. I am suggesting we use therightkey@ietf.org for that sort of
discussion.