Subject: [dane] I-D Action: draft-ietf-dane-registry-acronyms-00.txt

From: [email-masked]
Date: Thu, 19 Sep 2013 13:12:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Adding acronyms to simplify DANE conversations
	Author(s)       : Olafur Gudmundsson
	Filename        : draft-ietf-dane-registry-acronyms-00.txt
	Pages           : 5
	Date            : 2013-09-19

Abstract:
   Experience has show that people get confused using the three numeric
   fields the TLSA record.  This document specifies descriptive acronyms
   for the three numeric fields in the TLSA records.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Sep 2013 16:18:39 -0400

Dear DANE WG,

This starts a Working Group Last Call for draft-ietf-dane-registry-acronym.

The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/

Please review this (really short) draft to see if you think it is ready for publication
and comments to the list, clearly stating your view.

This WGLC ends Thu 03-Oct-2013.

Thanks,
Warren Kumari
(as DANE WG co-chair)

On Sep 19, 2013, at 4:12 PM, [email-masked] wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 

--
For every complex problem, there is a solution that is simple, neat, and wrong.
                -- H. L. Mencken

---

From: Andreas Schulze <[email-masked]>
Date: Thu, 19 Sep 2013 22:25:38 +0200

Zitat von Warren Kumari <[email-masked]>:

> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/
got a 404

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Sep 2013 20:33:16 +0000

Me too. 

This one works:

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Sep 2013 21:35:54 +0100

Typo. [1] works

S

[1] https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Sep 2013 16:46:39 -0400

> Typo. [1] works

Doh!

I have a script that generates these mails (and throws a reminder onto my calendar…) -- guess I need to add some better error checking…

It's one of those "I'm *sure* I can save myself heaps of time by writing a script to do this" and then you waste way more time writing the script[0][1].

W

[0]: http://xkcd.com/1205/

[1]: 
"I've just spent a cheerful hours of my time writing a program on my computer that will tell me instantly what the volume of the mound was. It's a very neat and sexy program with all sorts of pop-up menus and things, and the advantage of doing it the way I have is that on any future occasion on which I need to know the volume of a megapode nest, given its basic dimensions, my computer will give the answer in less than a second, which is a wonderful saving of time. The downside, I suppose, is that I cannot conceive of any further occasion that I am likely to need to know the volume of a megapode nest,... " Douglas Adams, "Last Chance to See"

--
"Real children don't go hoppity-skip unless they are on drugs."

    -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)

---

From: James Cloos <[email-masked]>
Date: Thu, 19 Sep 2013 18:00:49 -0400

PKIX-TA looks better than PKIX-CA; CA makes it look like it has to be an
association to a root cert.

It would be nice to have a better short description for type 3 than
Domain-issued certificate, notwithstanding the existance of that string
in rfc 6698.  DANE isn't about issuing certs, but rather about
establishing trust paths to them.  But I cannot come up with an
alternative.... 

Nits:

The paragraph: "It is expected that DANE parser's in applications and
DNS software MAY adopt parsing the acronyms for each field, installed
base MAY NOT get updated." could use better grammar.  Perhaps:

  s/each field, installed base/each field, but the installed base/

And perhaps /MAY NOT/may not/.  Unlike the first MAY, the may not isn't
really a 2119.  (The Nits link agrees.)

In the xml, I'd do:

   s(<c>CA     constraint</c>)(<c>CA constraint</c>)

it should look better in the output.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 Sep 2013 22:10:35 +0000

> The paragraph: "It is expected that DANE parser's in applications and

While we're "nitting", the plural "parsers" should not have an
apostrophe.  Agreed on PKIX-TA vs. PKIX-CA.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Thu, 19 Sep 2013 19:21:27 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

>> The paragraph: "It is expected that DANE parser's in applications and

VD> While we're "nitting", the plural "parsers" should not have an
VD> apostrophe.  Agreed on PKIX-TA vs. PKIX-CA.

Yikes.  Even with the cut-n-paste I missed the existance of that
apostrophe.  :^(

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Sep 2013 02:11:24 +0000

On Thu, Sep 19, 2013 at 10:10:35PM +0000, Viktor Dukhovni wrote:

> Agreed on PKIX-TA vs. PKIX-CA.

On second thought, I am not so sure, the CA constraint with usage
0, is NOT a trust-anchor, the trust-anchor is still the PKIX root CA.

This usage requires the presence of a given CA (root or intermediate)
in the chain, but does not promote that CA to a trust anchor (as
with usage 2).  So perhaps the original PKIX-CA is in fact better.

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 20 Sep 2013 07:48:24 +0200

> and comments to the list, clearly stating your view.

This is a step forward. It will make it easier to understand, discuss and configure DANE.

/O
>> ftp://ftp.ietf.org/internet-drafts/

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: James Cloos <[email-masked]>
Date: Fri, 20 Sep 2013 06:10:48 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> This usage requires the presence of a given CA (root or intermediate)
VD> in the chain, but does not promote that CA to a trust anchor (as
VD> with usage 2).  So perhaps the original PKIX-CA is in fact better.

On a ship with multiple anchors, each /is/ still an anchor.  Even if
the crew does not trust one at a time to hold the ship in place.

The type 0/1 tlsa are anchors, but the admin lacks trust in either
technology on its own and requires both technologies verify.

It also IMHO looks cleaner (perhaps also less confusing) to have one
bit specify EE|TA and the other specify CERT|DANE.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Sep 2013 14:27:10 +0000

> the crew does not trust one at a time to hold the ship in place.

I look at this as a ship with an anchor, and a "golden link" in
the chain (O.K., gold is not stronger than iron, but we won't take
this metaphor too literally).  Yes, the "golden link" can also be
a "golden anchor" when the TLSA record association data matches a
public root CA.

An interesting anomaly arises at a site that only explicitly trusts
an intermediate CA (via appropriate local software and configuration)
and is validating a chain that starts with an untrusted ancestor
CA that matches the TLSA RR:

	TLSA-CA -> ... -> local PKIX-TA -> ... -> EE certificate

Should DANE admit this chain?  Under the "2 anchors" analogy arguably
it should.  I think it should not.  The CA *constraint* in RFC 6698
was never intended to accept more certificate chains than one would
accept with PKIX alone, it is supposed to only be an additional check.
The PKIX trust anchor is primary and plays an assymetric role.

> technology on its own and requires both technologies verify.

I think this is a radical departure from PKIX terminology.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Sep 2013 14:30:01 +0000

> The PKIX trust anchor is primary and plays an assymetric role.

[ Muphry strikes!  The PKIX TA Measures how big an ass the verifier
  is for trusting it :-) ]

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Sep 2013 19:16:43 -0700

> with usage 2).  So perhaps the original PKIX-CA is in fact better.

PKIX is not clear if there are PKIX TAs that are not CAs, as we discussed extensively earlier in this WG. We do not need to open those wounds with molten salt. Either term is probably technically accurate, and we won't know for sure.

The rest of this document seems fine, and is a valuable addition to the DANE world.

--Paul Hoffman