Re: [dane] draft-ietf-dane-openpgpkey-00 comments

Paul Wouters <paul@nohats.ca> Tue, 22 April 2014 22:42 UTC

Return-Path: <paul@nohats.ca>
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 E8B0A1A02A4 for <dane@ietfa.amsl.com>; Tue, 22 Apr 2014 15:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level:
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] 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 jUQFo53Os4Oc for <dane@ietfa.amsl.com>; Tue, 22 Apr 2014 15:42:50 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCA91A0283 for <dane@ietf.org>; Tue, 22 Apr 2014 15:42:50 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3BC508009A; Tue, 22 Apr 2014 18:42:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1398206564; bh=VhfDY4uTIuBot6Aw6rEc/as0e2AS3YbaXD8DaNRB8Fc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lJJWNHYsMTP3GKtGYedVGWVRaa+IXL+9niJ0N0O3LSRv7jnllEtLEt5VRTSp2QzID XXJD25VjuRz12FGHZR7u7V3Joev9oQBgwtFn3pHzQXp0PWaA2HsRmXSlJH/bKY2Z42 gUMu07AiIh+P73JvD0iJ8/1TSEEVwKxOVVuAzq6w=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3MMggFf010374; Tue, 22 Apr 2014 18:42:43 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 22 Apr 2014 18:42:42 -0400
From: Paul Wouters <paul@nohats.ca>
To: James Cloos <cloos@jhcloos.com>
In-Reply-To: <m3d2g9dntz.fsf@carbon.jhcloos.org>
Message-ID: <alpine.LFD.2.10.1404221827080.32654@bofh.nohats.ca>
References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <53564F63.2010008@redhat.com> <m3d2g9dntz.fsf@carbon.jhcloos.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/lLBn7XsHvPh9_ynzhIUNg_6cz0w
Cc: dane@ietf.org
Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments
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: <http://www.ietf.org/mail-archive/web/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 Apr 2014 22:42:55 -0000

On Tue, 22 Apr 2014, James Cloos wrote:

> PS> What about CERT RR?
> PS> http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others):
>
> Cert uses the user portion of the email address as-is, and therefor only
> supports usernames which fit unalterred in dns.

Correct. Although we could have used the openpgpkey style _prefix to
avoid that, there were more issues with the CERT record type.

CERT also uses sub-typing, so you might end up getting all kind of types
of certificates (like a PKIX cert) that you don't want or need. Granted,
the _openpgpkey. prefix would at least prevent the non-malicious
contamination, but you might still get all kinds of weird stuff. From
what I understood, sub-typing was what really killed the CERT record,
and everyone since has been strongly urged to stay away from sub-typing,
and told to use _prefix. instead.

The CERT record also does not offer a nice presentation format for the
zone file. The RFC states:

       smith        IN CERT PGP 0 0 <OpenPGP binary>

Having binary in a zone is really a non-starter. Which is why OPENPGPKEY
uses base64 as the presentation format and the raw binary as the wire
format.

> Some aspects of the rfc are a bit terse.  Can you tell, for IPGP,
> whether the length octet is a bit-lenght or an octet-length?  Or
> which data, exactly, is digested to create the key tag?

IPGP specifies a URL, so now that url becomes another security hurdle.
What do you do when it is on https and you don't trust the CA, ignore.
What do you do when the URL is unreachable - is that censorship/attack?
With the full key in DNSSEC, you get the entire key using only one DNS
query without any followup HTTP(S) queries that you might not be able to
do for various (security/monitoring) reasons.

It seemed much more desirable to start a fresh dedicated RRTYPE over
fixing up the CERT RRTYPE and then needing to deal with servers that
only support the "old CERT type" versus ones that support the "new CERT
type". In other words, the pain of recycling was worse than just
starting fresh.

Paul