Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]

Mark Andrews <marka@isc.org> Mon, 09 December 2013 01:10 UTC

Return-Path: <marka@isc.org>
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 9CAA11AE18C for <dane@ietfa.amsl.com>; Sun, 8 Dec 2013 17:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.302
X-Spam-Level:
X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 HWup89S3TYLI for <dane@ietfa.amsl.com>; Sun, 8 Dec 2013 17:10:06 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1F1AE18B for <dane@ietf.org>; Sun, 8 Dec 2013 17:10:06 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id EE6452383C6 for <dane@ietf.org>; Mon, 9 Dec 2013 01:09:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B0A2D160446 for <dane@ietf.org>; Mon, 9 Dec 2013 01:17:55 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8F409160436 for <dane@ietf.org>; Mon, 9 Dec 2013 01:17:54 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5AA2FB5C445 for <dane@ietf.org>; Mon, 9 Dec 2013 12:09:45 +1100 (EST)
To: dane@ietf.org
From: Mark Andrews <marka@isc.org>
References: <A06891E1-01E0-40CC-A9A2-171CAA39AB79@kumari.net> <20131205175314.GH761@mournblade.imrryr.org> <E78C07CA-B742-43B2-8848-33DEB22A8014@kumari.net> <201312080234.rB82YeoW029387@new.toad.com> <20131208235315.GU761@mournblade.imrryr.org>
In-reply-to: Your message of "Sun, 08 Dec 2013 23:53:15 -0000." <20131208235315.GU761@mournblade.imrryr.org>
Date: Mon, 09 Dec 2013 12:09:44 +1100
Message-Id: <20131209010945.5AA2FB5C445@rock.dv.isc.org>
Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]
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: Mon, 09 Dec 2013 01:10:08 -0000

In message <20131208235315.GU761@mournblade.imrryr.org>rg>, Viktor Dukhovni writes
:
> On Sat, Dec 07, 2013 at 06:34:40PM -0800, John Gilmore wrote:
> 
> > > Any (strong) objections?
> > 
> > Yes, I object.  If there is no consensus on acronyms, we should stick
> > with what is in the current RFC 6698, rather than forwarding an
> > acronym proposal for adoption as a standard, even though we can't
> > agree on what it should say.  It's unnecessary, which probably
> > explains the paucity of responses, and divisive among those who did
> > respond.  It should be abandoned.
> 
> Perhaps the author is willing to take a look at the history of the
> thread, and propose one final set of names for the 4 usages that
> makes most sense to him.  We can then object or concur with those
> without (yet again) proposing changes.
> 
> I am not fundamentally opposed to human-readable TLSA RRs:
> 
>     ; _25._tcp.mx.example.com. IN TLSA 3 1 2
>     _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[

If anything other than numeric values appear in the records you
will break existing TLSA record parsers.  Names are useful when
describing thing.  They are no useful for portability and definitely
break the future proofing in the original presentation format.

For DNSKEY we display them as comments after the record.  The record
itself purely numeric and future proof.

e.g.

; <<>> DiG 9.10.0a1 <<>> dnskey . +rrcomments
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	DNSKEY

;; ANSWER SECTION:
.			4753	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=  ; KSK; alg = RSASHA256; key id = 19036
.			4753	IN	DNSKEY	256 3 8 AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33 4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V  ; ZSK; alg = RSASHA256; key id = 59085

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 09 11:52:43 EST 2013
;; MSG SIZE  rcvd: 450

TLSA, like DNSKEY, will need tools to take certs etc. and generate
TLSA records.  Those tools can use names but they emit records in
numeric form.

>     ; _25._tcp.mx.example.com. IN TLSA 2 0 2
>     _25._tcp.mx.example.com. IN TLSA TRUSTED-CA CERTIFICATE SHA2-512 {blob}
> 
>     ; _25._tcp.mx.example.com. IN TLSA 1 0 1
>     _25._tcp.mx.example.com. IN TLSA VALID-LEAF PUBLIC-KEY SHA2-256 {blob}
> 
>     ; _25._tcp.mx.example.com. IN TLSA 0 1 0
>     _25._tcp.mx.example.com. IN TLSA VALID-CA PUBLIC-KEY VALUE {blob}
> 
> As much possible, the acronyms should avoid jargon unfamiliar to
> their intended audience and in a full TLSA record should ideally
> read like a complete sentence, as above.
> 
> The dichotomy between "TRUSTED" (sufficient on its own) and "VALID"
> (not sufficient without external trust) is I think one reasonable
> way to communicate the usage values.
> 
> Anyway, I think it is up to the author to propose a final revision,
> or as John suggests, give up.
> 
> -- 
> 	Viktor.
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org