Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Oct 2013 13:31:24 -0700

Warren Kumari <[email-masked]> writes:

Looks like a good start and thanks for writing it Olafur!  But it's not
ready for publication without some cleanup.  Too many standard-things
are missing, such as acronym expansion and I'd feel guilty passing it
to the RFCEditors without us having caught such things.

Nits:

1)
   handle any case use in the input> The expectation is that by using
                              ^^^^^^
                              ??????

2) my alternate suggested should descriptions (I like the acronyms themselves):

    +-------+----------+-------------------------------------+-----------+
    | Value | Acronym  | Short Description                   | Reference |
    +-------+----------+-------------------------------------+-----------+
    |     0 | PKIX-TA  | PKIX Validated CA Reference         | [RFC6698] |
    |     1 | PKIX-EE  | PKIX Validated End-Entity Reference | [RFC6698] |
    |     2 | DANE-TA  | Validation TA Reference             | [RFC6698] |
    |     3 | DANE-EE  | Domain-issued certificate Reference | [RFC6698] |
    | 4-254 |          | Unassigned                          |           |
    |   255 | PrivCert | Reserved for Private Use            | [RFC6698] |
    +-------+----------+-------------------------------------+-------------+

                     Table 1: TLSA Certificate Usages

3) intro text (1 sentence?) to sections needed and expansion of other
   acronyms earlier in the document (PKIX, EE, )

4) ideally space align the section 3 records

                             inserted one space here
                             v
   _666._tcp.first.example.   TLSA PKIX-CA CERT SHA2-512 {blob}
   _666._tcp.second.example.  TLSA DANE-TA SPKI SHA2-256 {blob}

5) security considerations

   There is definitely something to consider if someone publishes both
   name records along with number records, and the client only parses
   number records.  What happens with this:

   _666._tcp.first.example.   TLSA 3       1    1        {blob}
   _666._tcp.first.example.   TLSA DANE-TA SPKI SHA2-256 {blob}

   Something needs to be said for that case; what would an existing
   implementation do?  drop both? take one?  Either way, it should be
   discussed/mentioned.

-- 
Wes Hardaker
Parsons

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Oct 2013 20:58:29 +0000

>    implementation do?  drop both? take one?  Either way, it should be

I'm confused I thought these were just user friendly names...  The
wire format of the DNS TLSA record is surely unchanged.  In which
case it is impossible to publish the second form, it is just an
input format in documentation (and perhaps source form zone files
in supporting DNS servers), but not a wire format.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Oct 2013 17:15:40 -0400

> 2) my alternate suggested should descriptions (I like the acronyms themselves):

<no hats>
Um, I'm a little confused (or you are, but probably it is me…)

I'm not quite sure what you are menacing by client here.  
If it is something like a stub resolver / application, it doesn't really see either of the above -- it just gets a big bag-o-bits.

If you are talking about someone putting this in a zone file,  whatever eats the zone file would continue to do what it does with any other record.
Example:
example            TYPE16 "foo"
example            TXT    "bar"

These are two text records, one with content "foo" and one with content "bar"
If someone does:
_666._tcp.first.example.   TLSA 3       1    1        {blob}
_666._tcp.first.example.   TLSA DANE-TA SPKI SHA2-256 {blob}

it is the same as if they had entered:
_666._tcp.first.example.   TLSA 3   1   1        {blob}
_666._tcp.first.example.   TLSA 2  1 1  {blob}
(or, if they have the same usage / selector / selector / match and {blob} then it is the same as if they had just entered the info twice).

If whatever eats the zone file is too old to understand the new enums / names, then it will continue to do what it does now with unknown garbage:

_666._tcp   TLSA COOKIEMONSTER BARNIE FRED   1234…

wkumari@vimes:~/tmp$ named-checkzone example.com example.com
dns_rdata_fromtext: example.com:26: near 'COOKIEMONSTER': not a valid number
example.com: file does not end with newline
zone example.com/IN: loading from master file example.com failed: not a valid number
zone example.com/IN: not loaded due to errors.

I suspect that I'm missing something / we are talking past each other…

W

--
"Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'."

    -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 05 Oct 2013 07:47:47 -0700

> in supporting DNS servers), but not a wire format.

I did actually mean to respond to that and say such, because I realized
that shortly afterward.  Sorry.

(though the zone file is still affected, I don't know of any software
that does partial reads of zone files and only takes the records it can understand)
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 05 Oct 2013 07:48:56 -0700

> Um, I'm a little confused (or you are, but probably it is me…)

Nope, it was me.  See my response to Viktor.
-- 
Wes Hardaker
Parsons

---

From: Warren Kumari <[email-masked]>
Date: Sat, 5 Oct 2013 16:35:33 -0700

On Sep 19, 2013, at 1:18 PM, Warren Kumari <[email-masked]> wrote:

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

… and we are done!

We judge that there is consensus on this document. We appreciate everyone's feedback and comments, and have asked the author to please incorporate the suggestions and rev' the doc. We will give folk a few days to object if their comments were misunderstood, and will then make it the IESG's problem :-)

Thanks again to Olafur for writing this.

W

> 
> Thanks,
> Warren Kumari
> (as DANE WG co-chair)
> 
> On Sep 19, 2013, at 4:12 PM, [email-masked] wrote:
> 
>> 
>> 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/
>> 
>> _______________________________________________
>> 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
> 
> 
> 
> 

--
"I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is." --Terry Prachett

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 6 Oct 2013 14:38:50 -0700

Sorry for being late on getting this in.

 1.  I do not understand the reasoning behind the 2119 language in the
introduction.  How would one test this in a protocol fashion?   The document
states that it does not change DANE in anyway, but there are requirement
language statements that can be made?  This should be stated in  natural
language not requirement language.  Section 1.1 can them be removed in its
entirety.

It is expected that DANE parsers in applications and DNS software will adopt
these acronyms for parsing and display purposes, however there are no
requirements that they do so.

 2.  In section 2, it states that the references should be both RFC 6698 and
this document, however that is not the way that the tables starting in
section 2.1 are laid out.  They only use RFC 6698 as a reference document.

3 s/input>/input./

4.  I don't think that this phrase "fewer bad TLSA records" is very helpful.
What is meant by a bad TLSA record?  Is this just ones where the fields were
put out of order or does it include ones where the certificate is
incorrectly hashed?  If the goal is to avoid issues with the certificates
and what is extracted, then doing something about what goes into the blob
would make sense as well.  I would agree that specifying how this would be
done is out of scope, but noting it as an issue would be reasonable.

5.  As I have stated before, I am not a fan of using DANE-TA for value 2.
To me this loses the fact that there will be PKIX processing that occurs
with this section.  I would strongly recommend that this become PKIX-TA.
The use of PKIX-TA for the value of 0 never made any sense since there is
not trust anchor decision that is associated with the certificate in this
record.  The only two records currently that have a trust anchor, as oppose
to a constraint, component are 2 and 3. 

6.  The note component at the end of section 2.1 should be deleted.

7.  In section 3, the descriptive text and the example records do not match
in very significant ways.

Jim

---

From: Mark Andrews <[email-masked]>
Date: Sun, 06 Oct 2013 16:45:59 +1100

> that does partial reads of zone files and only takes the records it can under

Any server that does a partial read is not rfc compliant.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 6 Oct 2013 22:47:42 +0000

> with this section.  I would strongly recommend that this become PKIX-TA.

I think that would confuse almost everyone.  The "PKI" part of PKIX
carries inappropriate in this context mental baggage.

Yes, any trust-anchor implies validating certificate chains,
performing name on the leaf, ...  Thus the mechanics of validating
usage 2 associations are very similar to the mechanics of doing
the same with an a-priori configured public CA trust anchor.  Alas,
when one hears PKIX, the associated mental baggage includes the
full panoply of public CAs and not does evoke the decentralized
DANE model.

Thus "TA" is IMHO already sufficient to imply all the relevant
technical features, without evoking unwanted mental associations.

> to a constraint, component are 2 and 3. 

Here, I've already agreed with you upthread, I think PKIX-CA is
better here (Paul Hoffman disagreed, but frankly I am not sure
how his response applies to the question at hand).

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Oct 2013 09:42:50 -0400

Viktor,
> full panoply of public CAs and not does evoke the decentralized
no for everyone :-). PKIX RFCs do not address the public TA/CA
model in browsers to which you refer. So the mental baggage to which
you refer is an example of an inappropriate-sized carry on (to run
that metaphor into the ground).

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Oct 2013 14:52:33 +0000

On Mon, Oct 07, 2013 at 09:42:50AM -0400, Stephen Kent wrote:
> So the mental baggage to which you refer is an example of an
> inappropriate-sized carry on (to run that metaphor into the ground).

Yes, but I still think many will find PKIX-TA confusing as a
description of usage 2.  It is easier to roughly divide the usages
into

  - 0/1 (PKIX, that is public CA verified, DNSSEC constrained)

and

  - 2/3 (DANE, that is DNSSEC verified)

though I freely admit that indeed the PKIX specification is
silent on the origin of the TA, and technically quite suitable to
usage 2.  Indeed many of the implementation flaws I pointed out
some months back this spring, (in then extant DANE implementations),
were related to failure to properly verify usage 2 chains (it was
a common error to simply check that the peer's chain contained the
associated TA certificate without checking that the TA actually
authenticates a valid chain leading to the EE certificate).

So perhaps the bottom line is that no matter which acronyms we
adopt, confusion will reign until we have ample implementation
guidance (and even then of course some will remain perpetually
confused).

I originally had implementation notes in the DANE ops draft, but
decided to focus just on operational issues, in the end.  Perhaps
there should be a separate document with guidance and warnings for
implementation developers.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 7 Oct 2013 08:20:10 -0700

So, while I have sure that I have the details partly wrong, consider the
case of people doing a PGP certificate set here.

They could/would use DANE-EE in the event that the key ring was self-signed.
This is the key to be matched and trusted.

However they would not use DANE-TA in the event that a key ring that was
self-signed was to be used to validate a second key wrong.  In this case
there is a root of trust (i.e. a TA) and then a second level signed PGP key
which is used in the TLS session to do the appropriate things.  This allows
for the TLS key to be rotated more frequently.  But there is no PKIX
validation in this case and thus the use of DANE-TA, which seems logical, is
wrong.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Viktor Dukhovni
> Sent: Sunday, October 06, 2013 3:48 PM
> To: [email-masked]
> Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym
> 
> > To me this loses the fact that there will be PKIX processing that
> > occurs with this section.  I would strongly recommend that this become
> PKIX-TA.
> 
carries
> inappropriate in this context mental baggage.
> 
> Yes, any trust-anchor implies validating certificate chains, performing
name
> on the leaf, ...  Thus the mechanics of validating usage 2 associations
are
> very similar to the mechanics of doing the same with an a-priori
configured
> public CA trust anchor.  Alas, when one hears PKIX, the associated mental
> baggage includes the full panoply of public CAs and not does evoke the
> decentralized DANE model.
> 
> Thus "TA" is IMHO already sufficient to imply all the relevant technical
> features, without evoking unwanted mental associations.
> 
> > The use of PKIX-TA for the value of 0 never made any sense since there
> > is not trust anchor decision that is associated with the certificate
> > in this record.  The only two records currently that have a trust
> > anchor, as oppose to a constraint, component are 2 and 3.
> 
> Here, I've already agreed with you upthread, I think PKIX-CA is better
here
> (Paul Hoffman disagreed, but frankly I am not sure how his response
applies
> to the question at hand).
> 
> --
> 	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Oct 2013 15:56:42 +0000

On Mon, Oct 07, 2013 at 08:20:10AM -0700, Jim Schaad wrote:

> self-signed was to be used to validate a second key wrong.

[ Typo for "ring" as "rong" auto-corrected to "wrong".

"Damn you auto-connect!"
Oops, sorry: "Damn you auto-corrupt!"
Oh, never mind...  ]

> In this case

The DANE usages defined thus far are for TLS with X.509v3 certificates.
These may be self-signed, issued by a private self-signed TA, or
issued by a public CA.

I don't see where hypothetical PGP certificates fit in.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 7 Oct 2013 13:41:00 -0700

> Sent: Monday, October 07, 2013 8:57 AM
> To: [email-masked]
> > However they would not use DANE-TA in the event that a key ring that
> > was self-signed was to be used to validate a second key wrong.
> 
> > there is a root of trust (i.e. a TA) and then a second level signed
> > PGP key which is used in the TLS session to do the appropriate things.
> > This allows for the TLS key to be rotated more frequently.  But there
> > is no PKIX validation in this case and thus the use of DANE-TA, which
> > seems logical, is wrong.
> 
> These may be self-signed, issued by a private self-signed TA, or issued by
a
> public CA.

It was an attempt to point out that trust anchors could be done for more
than just PKIX certificates, but it apparently did not succeed.  The issue
is that if you have a PGP trust anchor and a PKIX trust anchor they should
probably not have the same descriptive name (and hence value) since the side
semantics are not the same.

Jim

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 16 Oct 2013 16:29:37 -0400

James, 

Thanks for the edits I applied them, 
PKIX-CA vs TA I'm not sure what the consensus of the WG was and ask chairs to rule on that. 

	Olafur

On Sep 19, 2013, at 6:00 PM, James Cloos <[email-masked]> wrote:

> 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: Olafur Gudmundsson <[email-masked]>
Date: Wed, 16 Oct 2013 16:29:54 -0400

>   handle any case use in the input> The expectation is that by using
Fixed

> 2) my alternate suggested should descriptions (I like the acronyms themselves):

I ask chairs to rule if your rewording has traction 
I like it but there were no voices of support and this changes the
registry more than the one column that I set out to add. 

>   acronyms earlier in the document (PKIX, EE, )
No 

>   _666._tcp.second.example.  TLSA DANE-TA SPKI SHA2-256 {blob}
fixed. 

>   _666._tcp.first.example.   TLSA DANE-TA SPKI SHA2-256 {blob}
This is impossible as the DNS wire fomat is numbers.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 16 Oct 2013 16:41:14 -0400

> language not requirement language.  Section 1.1 can them be removed in its

There two instances of MAY and MAY NOT
I reworded them and removed section 1.1

> section 2.1 are laid out.  They only use RFC 6698 as a reference document.

There are two different set of references 
a) the references for the Registry itself 
b) the references for each allocation in the registry. 

This document only applies to the first one 
and that is what I said. 

Fixed

> done is out of scope, but noting it as an issue would be reasonable.

I agree and removed that sentence. 

> to a constraint, component are 2 and 3. 

I leave a call on that to the wise chairs :-) 
I do not care personally 

> 6.  The note component at the end of section 2.1 should be deleted.

Gone

> in very significant ways.

I must be dense, there is not supposed to be any correlation between the
two paragraphs in section 3 they are supposed to be separate examples. 
thanks for good comments. 

	Olafur