Subject: Re: Last Call: <draft-ietf-dane-protocol-19.txt> - Referring to the DANE protocol and DANE-denoted certificate associations

From: =JeffH <[email-masked]>
Date: Tue, 24 Apr 2012 15:23:23 -0700

[ these are excerpts from a current thread on dane@ that I'm now denoting as an 
IETF-wide Last Call comment ]

Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700:
 >
 > On Apr 20, 2012, at 10:50 AM, =JeffH wrote:
 >
 >> Various specs are going to have need to refer to the DANE protocol
 >> specification a well as describe the notion of domain names that map to
 >> TLSA records describing certificate associations.
 >>
 >> In working on such language in draft-ietf-websec-strict-transport-sec,
 >> here's the terms I'm using at this time and their (contextual) meaning..
 >>
 >> DANE protocol
 >>   The protocol specified in draft-ietf-dane-protocol (RFC# tbd).
 >>
 >
 > There is an issue here that we haven't dealt with, which is that "DANE
 > protocol" doesn't really make sense because we might be adding additional
 > protocols for certificate associations for things other than TLS. For your
 > doc, you should be saying "TLSA protocol", not "DANE protocol" because HSTS
 > is specific to TLS. (More below.)

After further perusal of draft-ietf-dane-protocol-19, if I understand 
correctly, 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", yes=?

i.e. we could define another separate spec for mapping Foo protocol's 
keys/certs to DNS RRs, and call 'em FOOA, and then in following this naming 
approach, refer to the protocol of using them while establishing Foo 
connections as the "FOOA protocol", yes?

Paul Hoffman further explained on Sat, 21 Apr 2012 13:38:38 -0700:
 >
 > On Apr 20, 2012, at 3:34 PM, =JeffH wrote:
 >>
 >> Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700:
 >>
 >> > On Apr 20, 2012, at 10:50 AM, =JeffH wrote:
 >> >
 >> > There is an issue here that we haven't dealt with, which is that "DANE
 >> > protocol" doesn't really make sense because we might be adding additional
 >> > protocols for certificate associations for things other than TLS.
 >>
 >> Yep. "DANE" is a working group name. But, I was working from the
 >> specification name per the present spec.
 >>
 >> > ...
 >> > Proposal for [-dane-protocol] spec:
 >> >
 >> > The protocol in this document can generally be referred to as the "TLSA
 >> > protocol".
 >>
 >> So as a practical matter, if we wish to refer to this particular spec as
 >> defining the "TLSA protocol", then perhaps the spec title should reflect
 >> that such that the RFC Index is searchable for that "TLSA" term.
 >
 > The WG already decided against that (unfortunately).

I agree it is unfortunate and respectfully suggest that this decision be 
revisited.

Many (most?) people have been referring to the protocol being worked on by the 
working group (which is now draft-ietf-dane-protocol) as "the DANE protocol" or 
simply "DANE" for as long as the WG has been formed, /plus/, the present title 
of spec is..

   The DNS-Based Authentication of Named Entities (DANE) Protocol for
   Transport Layer Security (TLS)

I think it will just continue to unnecessarily sow confusion if the term "TLSA" 
doesn't somehow get into the spec title and thus into the various RFC indexes 
(whether or not the suggested statement above explicitly naming the protocol 
"TLSA protocol" is added to the spec (I think it should be added)).

Ways to accomplish addressing the spec title issue could be..

   TLSA: The DNS-Based Authentication of Named Entities (DANE) Protocol for
   Transport Layer Security (TLS)

..or..

   The DNS-Based Authentication of Named Entities (DANE) Protocol for
   Transport Layer Security (TLS): TLSA

HTH,

=JeffH

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Apr 2012 08:48:07 -0400

+1

The name should reflect the final product, not the path taken to get there.

If people were to use these records then they would see them in the
DNS zone and see them listed as TLSA and look for an RFC with that
name. Only the people who were involved in the group would know that
DANE and TLSA are the same thing.

On Tue, Apr 24, 2012 at 6:23 PM, =JeffH <[email-masked]> wrote:
> [ these are excerpts from a current thread on dane@ that I'm now denoting as
> an IETF-wide Last Call comment ]
>
> instances will nominally be assigned their own names, where a case-in-point
> is the "TLSA Protocol", yes=?
>
> Many (most?) people have been referring to the protocol being worked on by
> the working group (which is now draft-ietf-dane-protocol) as "the DANE
> protocol" or simply "DANE" for as long as the WG has been formed, /plus/,
> the present title of spec is..
>
> I think it will just continue to unnecessarily sow confusion if the term
> "TLSA" doesn't somehow get into the spec title and thus into the various RFC
> indexes (whether or not the suggested statement above explicitly naming the
> protocol "TLSA protocol" is added to the spec (I think it should be added)).
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
Website: http://hallambaker.com/