Subject: [dane] Record creators and MUST? And TLSA protocol name.

From: John Gilmore <[email-masked]>
Date: Thu, 16 Feb 2012 02:29:36 -0800

Section 7 specifies particular requirements on implementations in
general, though it is entitled "Mandatory-to-Implement Algorithms".
(That should possibly be changed.)

The first graf requires:

   A system creating TLSA records that conforms to this specification
   MUST be able to create TLSA records containing certificate usages 0,
   1, 2, and 3.

I don't understand why we MUST this.  I could presumably build
a piece of software that only created TLSA records that used 
certificate usage 3, and there would be nothing wrong about it.
This software doesn't *interpret* TLSA records that arrive from
elsewhere; it only creates them.  So there's no interoperability
problem.

This graf can't be talking about a DNS server or a DNS client library,
since they will treat the RDATA as opaque.  Other DNS software
that translates between text and binary RR representations
should not be enforcing any constraints on the four fields in the
RDATA (e.g. you could make a TLSA RR with certificate usage 255 or 137
and the software should be able to parse or print it properly), but I
don't think that needs to be a SHOULD or MUST, since it has no
interoperability impact.  Users who buy software that screws their
ability to experiment or use extensions are not our protocol's
problem.

So this graf is really about software that e.g. creates a TLSA text
record from a PKIX cert, or from command line arguments.  And again,
interoperability doesn't require that every variant of every field be
usable or used.

I recommend striking the entire first paragraph, which MUSTs and
SHOULDs the cert usage, selector, and hash type fields for systems
*creating* TLSA records.

For TLSA clients (the second paragraph), the MUST and SHOULDs are in
accord with the issue tracker.  But let's fix the name from "TLS
clients conforming to this specification" to "TLSA clients".  That
seems to be how we're thinking about this.

This brings up the general question of whether we should be referring
to this protocol as "TLSA" in places where we talk about "this
protocol" or "this document".  Indeed we seem to not have come up with
a name for this protocol anywhere; I propose that we call it the "TLSA
protocol".  That should simplify naming in a number of places,
including the title of the RFC.

(The only catch is: what is TLSA an acronym of?  Transport Layer
Security Association?  Transport Layer Security Augmentation?)  Or, as
in DANE, Transport Layer Security Authentication?  The RRTYPE TLSA was
defined in the protocol-00.txt, without a specified expansion.
Whatever acronym expansion we use, we should use in the RFC title.  See
https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt
section 4.2 (Full Title):

   Choosing a good title for an RFC can be a challenge.  A good title
   should fairly represent the scope and purpose of the document without
   being either too general or too specific.

   Abbreviations (e.g., acronyms) [ABBR] in a title (as well as the
   Abstract and the body) must generally be expanded when first
   encountered.  The exception is abbreviations that are so common that
   every participant in the IETF can be expected to recognize them
   immediately; examples include (but are not limited to) TCP, IP, SNMP,
   and FTP.  Some cases are marginal, and the decision on expansion may
   depend upon the specific title.  The RFC Editor will make the final
   judgment, weighing obscurity against complexity.

   It is often helpful to follow the expansion with the parenthesized
   abbreviation, as in the following example:

                            Encoding Rules for the
            Common Routing Encapsulation Extension Protocol (CREEP)
  
So, perhaps "Transport Level Security Authentication (TLSA) using DNS Security"
as a title?

	John

---

From: Bill Owens <[email-masked]>
Date: Thu, 16 Feb 2012 10:27:26 -0500

> elsewhere; it only creates them.  So there's no interoperability

Lifting that restriction seems reasonable; I don't see any reason to limit implementations that way.

> seems to be how we're thinking about this.

+1, though I'm not sure that's the right name (see below)

> including the title of the RFC.

I'll admit that I haven't really considered this question, but I was under the impression that the protocol is known as 'DNS-Based Authentication of Named Entities (DANE)' and the DNS record that implements it is called 'TLSA', without any particular expansion. That usage may not be consistent, though; for example the Abstract might better say 'DANE (DNS-based...) uses the TLSA record in the DNS to provide bindings of keys to domains... '

If that's the case, the contentious proxy considerations paragraph is wrong in referring to 'the TLSA protocol', and of course I wrote a revision of it containing those words, so clearly I haven't been thinking precisely about the protocol name either. . .

> So, perhaps "Transport Level Security Authentication (TLSA) using DNS Security"

Or in keeping with RFC6394, 'The DNS-Based Authentication of Named Entities (DANE) Protocol Version 1.0'

Bill.

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 16 Feb 2012 19:27:02 +0100

Hi,

On 02/16/2012 04:27 PM, Bill Owens wrote:
>> So, perhaps "Transport Level Security Authentication (TLSA)
>> using DNS Security" as a title?
> 

There will also be a spec for SMIMEA, that is also be a 'The DNS-Based
Authentication of Named Entities (DANE)' protocol. So 'The DNS-Based
Authentication of Named Entities (DANE) for Transport Layer Security
(TLS) Protocol' would be better. Although that might be a bit long..

- --
Pieter

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 19 Feb 2012 17:46:41 -0800

> (That should possibly be changed.)

Probably so: Mandatory-to-Implement Features

> SHOULDs the cert usage, selector, and hash type fields for systems

This works for me. Any objections to doing this?

> seems to be how we're thinking about this.

Fully disagree that is how "we're" thinking about this. TLSA is not a protocol (there was only one mention of that phrase in the doc, will be fixed in the next version), it is a type of DNS record. A type of DNS record doesn't have "clients".

> including the title of the RFC.

Disagree with the latter; agree that we should not say "this protocol" in the document. That was sloppy, so we'll fix the handful of cases of that in the next version.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 17:03:34 +0100

Hi WG,

anybody else caring for name?

We have these proposals:

a) Using Secure DNS to Associate Certificates with Domain Names For TLS

b) The DNS-Based Authentication of Named Entities (DANE) Protocol Version 1.0

c) Transport Level Security Authentication (TLSA) using DNS Security

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

Please vote now.

My preference would be:
d>c>a

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 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: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Feb 2012 11:11:30 -0500

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

I would like my bike shed to be…

b > c > d > a

(Only, remove the "The" and "Protocol Version 1.0" from b)

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 24 Feb 2012 17:16:34 +0100

Hi,

> Transport Layer Security (TLS) Protocol

d > c > b > a

But d written as: 'The DNS-Based Authentication of Named Entities
(DANE) Protocol for Transport Layer Security (TLS)', to associate the
word protocol with DANE and not with TLS.

- --
Pieter

---

From: Bill Owens <[email-masked]>
Date: Fri, 24 Feb 2012 11:28:29 -0500

> word protocol with DANE and not with TLS.

Even though I originally proposed b, I prefer Pieter's wording of d (since it was pointed out that there will be DANE for other purposes as well).

Bill.

---

From: Scott Schmit <[email-masked]>
Date: Fri, 24 Feb 2012 22:28:59 -0500

> word protocol with DANE and not with TLS.

d (as rewritten above) >> c >> a

I don't like b at all; our charter has us working on DANE for IPsec
next, and there's talk of doing it for S/MIME as well.

-- 
Scott Schmit

---

From: Peter Koch <[email-masked]>
Date: Sun, 26 Feb 2012 18:37:56 +0100

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

i do not care much about the name, but (a) and (c) suggest that DNSSEC
rather than DNS is the key part in associating the TLSA record (or its content)
with a (domain) name.  That would be plain wrong. (d) or (b) are fine.

-Peter

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 27 Feb 2012 14:56:55 +0100

To not keep this issue open too long I think we have clear winner:

d) rewritten as:

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

Thanks to all,
O.

On 26. 2. 2012, at 18:37, Peter Koch wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane