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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ 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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]