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

From: Warren Kumari <[email-masked]>
Date: Sun, 1 Dec 2013 14:00:41 -0500

On Oct 16, 2013, at 4:41 PM, Olafur Gudmundsson <[email-masked]> wrote:

> 
> On Oct 6, 2013, at 5:38 PM, Jim Schaad <[email-masked]> wrote:
> 
>> 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.
>> 
> 
> There two instances of MAY and MAY NOT
> I reworded them and removed section 1.1
> 
>> 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.
>> 
> 
> 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. 
> 
> 
>> 3 s/input>/input./
>> 
> Fixed
> 
>> 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.
>> 
> 
> I agree and removed that sentence. 
> 
>> 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. 
> 
> I leave a call on that to the wise chairs :-) 
> I do not care personally 

I'm not sure where these "wise chairs" are, but I believe we have consensus for PKIX-TA.
It's not ideal but seems good enough.

Apologies for the delay, digging out from under backlogged mail from the NANOG/RIPE/IETF/ICANN roadshow…

W

> 
>> 
>> 6.  The note component at the end of section 2.1 should be deleted.
> 
> Gone
> 
>> 
>> 7.  In section 3, the descriptive text and the example records do not match
>> 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
> 
>> Jim
>> 
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 

-- 
"I think it would be a good idea." 
- Mahatma Ghandi, when asked what he thought of Western civilization

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 1 Dec 2013 16:03:11 -0500

New version  addressing this call by the chairs posted. 

	Olafur

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 Dec 2013 21:34:28 +0000

On Sun, Dec 01, 2013 at 02:00:41PM -0500, Warren Kumari wrote:

> I'm not sure where these "wise chairs" are, but I believe we have
> consensus for PKIX-TA.  It's not ideal but seems good enough.

[ FWIW, I still maintain that PKIX-CA (being just a constraint and
  not necessarily an anchor for the chain) is correct, while PKIX-TA
  is misleading.  PKIX-CA is quite different from DANE-TA, where the
  association data in fact specifies a trust-anchor.  Multiple
  implementations have failed to correctly capture the semantics
  of DANE-TA, we should not IMNSHO make PKIX-CA and DANE-TA appear
  to be more similar than they are. ]

Suggested word-smithing final touches:

In the Abstract change:

   -----
   Experience has show that people get confused using the three numeric
   fields the TLSA record.
   -----

to:

   -----
   Experience has shown that people are sometimes confused by the
   three numeric fields in the TLSA record.
   -----

Replace the introduction:

   -----
   In discussions on how to add DANE [RFC6698] technology to new
   protocols/services people repeatedly have got confused as what the
   numeric values stand for and even the order of the fields of a TLSA
   record.  This document updates the IANA registry definition for TLSA
   record to add a column with acronym for each specified field, in
   order to reduce confusion.  This document does not change the DANE
   protocol in any way.

   It is expected that DANE parsers in applications and DNS software can
   adopt parsing the acronyms for each field.
   -----

with:

   -----
   In discussions on how to add DANE [RFC6698] technology to new
   protocols/services there has been repeated confusion as to what
   the numeric values stand for and even the order of these fields
   in a TLSA record.  This document updates the IANA registry
   definition for the TLSA record to add an acronym for each
   specified field, in order to reduce confusion.  This document
   does not change the DANE protocol in any way.

   It is expected that parsers in applications and DNS software
   will accept the new acronyms as alternatives to the underlying
   numeric values in the presentation format of TLSA records.
   -----

In "IANA considerations replace:

   -----
   [RFC6698] and this document are both to be the reference documents
   for the three sub-registries.

   As these acronyms are offered for human consumption, case does not
   matter, it is expected that software that parses TLSA records will
   handle either upper or lower case use as input.
   -----

with:

   -----
   [RFC6698] and this document will be the reference documents for
   the three sub-registries.

   As these acronyms are offered for human consumption, case does not
   matter, it is expected that software that parses TLSA records will
   process the acronyms in a case-insensitive manner.
   -----

In "Acknowledgements" replace:

   -----
   Scott Schmit offered real good suggestions to decrease the
   possibility of confusion.  Viktor Dukhovni provided comments from
   expert point of view.  Jim Schaad, Wes Hardaker and Paul Hoffman
   provided feedback during WGLC.
   -----

with

   -----
   The author thanks Jim Schaad, Paul Hoffman, Scott Schmit, Viktor
   Dukhovni and Wes Hardaker for their helpful comments.
   -----

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 1 Dec 2013 18:50:43 -0800

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Sunday, December 01, 2013 1:34 PM
> To: [email-masked]
> Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym
> 

+1