Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:20:03 +0200

Jeff,

we believe that your issues:

http://www.ietf.org/mail-archive/web/dane/current/msg04695.html
http://www.ietf.org/mail-archive/web/dane/current/msg04713.html

should be fixed in -20.  Could you please confirm?  Thank you.

Ondrej

On 25. 4. 2012, at 18:52, =JeffH wrote:

> Paul Hoffman replied:
> >>> We use the term "usable certificate association" in section 4. For your
> >>> spec, how about:
> >>>
> >>> trusted certificate association
> >>>   A certificate association specified in a
> >>>   TLSA record that is determined to be usable in the TLSA spec.
> >>>
> >>
> >> In that case, I'd be inclined to just use "usable cert association" rather
> >> than redefine it with the qualifier "trusted" (ie, if that's not what the
> >> -dane-protocol spec defines).
> >>
> >> Also, it would be helpful if the term "usable certificate association" is
> >> explicitly defined in a clearly referenceable manner in -dane-protocol.
> >>
> >> This could be done by making that final para of section 4 a titled
> >> subsection, e.g..
> >>
> >> 4.1 Usable Certificate Association
> >>
> >> but since I notice that section 4 is entitled "Use of TLSA Records in TLS"
> >> it should perhaps be..
> >>
> >> 4.1 Usable TLS Certificate Association
> >
> > I like the former.
> 
> Actually, in re-reading section 4 of -dane-protocol I wouldn't turn that last para into a subsection -- because as you note..
> 
> 
> > The definition of what is "usable" goes on for many paragraphs..
> 
> 
> Rather, I'd  be inclined to add something akin to this to "1.4. Terminology"..
> 
>  Usable TLS Certificate Association
>    A TLS certificate association that has passed all the tests specified
>     in Section 4 "Use of TLSA Records in TLS".
> 
> 
> there's some other terminological issues I'll send in another msg as a Last Call comment.
> 
> HTH,
> 
> =JeffH
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: =JeffH <[email-masked]>
Date: Thu, 03 May 2012 10:01:10 -0700

> should be fixed in -20.  Could you please confirm?  Thank you.

thx, I will endeavor to review in next day or two.

=JeffH

---

From: =JeffH <[email-masked]>
Date: Thu, 03 May 2012 15:27:57 -0700

> http://www.ietf.org/mail-archive/web/dane/current/msg04695.html

yes, the above issue is addressed in -20.

 > http://www.ietf.org/mail-archive/web/dane/current/msg04713.html

many items are fixed in -20, including the most important ones it seems. (thx)

since there were several items, i've identified below fixed vs not fixed and 
added some further thoughts on a few.  the two marked with [*] i'd be inclined 
to really fix.

however, I'll leave it up to you -- I won't fall on my sword over any of 'em at 
this point.

HTH,

=JeffH

 > Some additional modest last call comments on draft-ietf-dane-protocol-19...
 >
 > terminological issues
 > ---------------------
 >
 > The "usage" notion has at least five term/phrase variations used in the
 > spec. I found this quite confusing. Here's the variations I find..
 >
 > usage = usage type = certificate usage = certificate usage type = TLSA Usages
 >
 >
 > I suggest settling on one or two phrases for most all occurances. I suggest
 > using "certificate usage type" in (almost) all cases, and "usage type"
 > perhaps in cases where the bare term "usage" is presently used. To help out,
 > here's an updated TLSA RDATA Wire Format diagram..
 >

the above set of issues are fixed. (thanks!)

 > Separately, the term "TLSA certificate association" is used in a few places,
 > and should probably be "TLS certificate association" for consistency.

[*]

the term "TLS certificate association" is now established in the 1st para of S 
2, but then "TLSA certificate association" (note the "A" at the end of "TLS") 
is used throughout the spec. Is that the actual intention or a cut-and-paste 
mistake?  using either phrase is fine by me, i'd just be utterly consistent.

 > I also found the term "TLSA association" used on pages 22 & 23, which ought
 > to be "TLS certificate association", yes?

the above is not addressed.

 > Section 8.1 introduces the somewhat ambiguous term "DANE client", which is
 > contrasted with "common TLS clients" and "current TLS client". Perhaps
 > "TLSA-aware TLS client" is more appropriate here than "DANE client",
 > especially if this protocol is referred to as the "TLSA protocol"?

"DANE client" is now used only once at beginning of S 8.1. thus this issue is 
mostly addressed.

  I think in this section the intended connotation of that term is "TLSA-aware 
TLS client" ? (that's what I would use)

 > editorial items
 > ---------------
 >
 >  > 1.1. Background of the Problem
 >
 > [ I'd entitle this section "Background and Motivation" ]

fixed.

 >
 > last para:
 >
 >  >    DNS-Based Authentication of Named Entities (DANE) offers the option
 >  >    to use the DNSSEC infrastructure to store and sign keys and
 >  >    certificates that are used by TLS.
 >
 > If in fact the term "DANE" (and its expansion) names a class of Secure
 > DNS-based cert/key-to-domain-name associations, and protocols for
 > particular instances will nominally be assigned their own names, where a
 > case-in-point is the "TLSA Protocol", then..
 >
 > s/TLS/security protocols/
 >
 > ..in the above-quoted sentence.

the above is not addressed.

 >  > 1.2 Securing the Association with a Server's Certificate
 >
 > which association is this section title referring to? (it's ambiguous)
 >
 > Suggested more precise section title:
 >
 > "Securing the Association of Domain Name and TLS Server Certificate"

fixed.

 >  >             Currently, the client must extract the domain name from the
 >  >    certificate and must successfully validate the certificate, including
 >  >    chaining to a trust anchor.
 >
 > I found the above description unnecessarily imprecise, though recognizing
 > the desire to provide only a brief overview here. A suggested modest
 > rewrite:
 >
 >     Currently, the client must extract the domain name from the certificate
 >     and validate it [RFC6125], and must also successfully validate the
 >     certificate, including chaining to a CA's trust anchor [RFC5280].
 >     However, as explained above in Section 1.1, essentially any CA may
 >     have issued the certificate for the domain name.

[*]

not fixed.

 >  > 2. The TLSA Resource Record
 >  >
 >  >    The TLSA DNS resource record (RR) is used to associate a certificate
 >  >    with the domain name where the record is found.
 >
 > suggested clarification..
 >
 >    The TLSA DNS resource record (RR) is used to associate a TLS server
 >    certificate or public key with the domain name where the record is found,
 >    thus forming a "TLS certificate association".
 >
 > Otherwise, "TLS certificate association" is only tacitly defined.

fixed.

 >  > 2.1.1. The Certificate Usage Field
 >  >
 >  >
 >  >    A one-octet value, called "certificate usage" or just "usage",
 >  >    specifies the provided association that will be used to match the
 >  >    target certificate from the TLS handshake.
 >
 > In the above, as well as two more instances in the paragraphs following the
 > above, I suggest..
 >
 >    s/target certificate/presented certificate/
 >
 > ..to be more consistent with RFC6125.

not fixed.

 >  > 2.1.4. The Certificate Association Data Field
 >  >
 >  >
 >  >    The "certificate association data" to be matched.  This field
 >  >    contains the data to be matched.
 >
 > The 2nd sentence "This field contains the data to be matched." is redundant.

fixed.

 >  > 5. TLSA and DANE Use Cases and Requirements
 >  >                   .
 >  >                   .
 >  >                   .
 >  >    Combination  -- Multiple TLSA records can be published for a given
 >  >       host name, thus enabling the client to construct multiple TLSA
 >  >       certificate associations that reflect different DANE assertions.
 >  >       No support is provided to combine two TLSA certificate
 >  >       associations in a single operation.
 >  >
 >  >    Roll-over  -- TLSA records are processed in the normal manner within
 >  >       the scope of DNS protocol, including the TTL expiration of the
 >  >       records.  This ensures that clients will not latch onto assertions
 >  >       made by expired TLSA records, and will be able to transition from
 >  >       using one DANE public key or certificate usage type to another.
 >
 >
 > suggested rewrite eliminating the not-defined-in-RFC6394 terms "DANE
 > assertion" and "DANE public key"...
 >
 >     Combination  -- Multiple TLSA records can be published for a given
 >        host name, thus enabling the client to construct multiple different
 >        TLS certificate associations. No support is provided to combine two
 >        TLS certificate associations in a single operation.
 >
 >     Roll-over  -- TLSA records are processed in the normal manner within
 >        the scope of DNS protocol, including the TTL expiration of the
 >        records.  This ensures that clients will not latch onto assertions
 >        made by expired TLSA records, and will be able to transition from
 >        using one TLSA-asserted public key or certificate usage type to
 >        another.

fixed.

 >  > 7.2. TLSA Usages
 >  >
 >  >
 >  >    This document creates a new registry, "Certificate Usages for TLSA
 >  >    Resource Records".
 >
 > suggested modest revision for terminological consistency:
 >
 >   7.2. TLSA Certificate Usage Types
 >
 >     This document creates a new registry, "TLSA Resource Record Certificate
 >     Usage Types"

fixed.

---
end