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

Note: This ballot was opened for revision 19 and is now closed.

(Wesley Eddy) Yes

(Stephen Farrell) Yes

Barry Leiba Yes

Comment (2012-06-06 for -21)
No email
send info
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- 1.2, last paragraph --
   This document only
   relates to securely associating certificates for TLS and DTLS with
   host names; other security protocols are handled in other documents.

This makes it sound like there are other documents related to DANE for things like IPsec and SSH.  They're about keys in DNS in general, and the next sentence refers to non-DANE stuff.  Then the last sentence comes back to TLS/DTLS.

I suggest doing this paragraph as two paragraphs, this way:

   Sentence 1.  Sentence 2.  Sentence 5.

   Sentence 3.  Sentence 4.

And then re-phrase the new second paragraph to say something like, "...retrieving certificates from DNS for other protocols is handled in other documents."

-- 1.3 --
   The DNSSEC signature needs to be validated on all responses
   that use DNSSEC in order to assure the proof of origin of the data.

Don't *all* responses need to use DNSSEC, as well?  Or is it possible to have a mixture of DNSSEC and unsecured DNS responses?  Maybe it would be better to say it this way?:

NEW
   The DNSSEC signature needs to be validated on all DNS responses
   in order to assure the proof of origin of the data.

-- 2.2 --
   [in three places] MUST be represented as an 8-bit
   unsigned decimal integer.

What does "decimal integer" mean?  I presume you should just take the word "decimal" out in all three places.  Or is there something I'm missing?

-- 2.3 --
The order here is odd: you haven't introduced the _443 and _tcp things yet, but you're showing them in the examples.  Maybe that's OK, but it feels a little confusing to me.  Consider moving the examples after Section 3 (to a new Section 4).

-- 4.1 --
      If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, this MUST cause TLS not to be started

Clearly, "bogus" is a technical term that means something distinct from "indeterminate or insecure" (in the next bullet).  Alas, I cut class the day they explained "bogus", and so I need an explanation.  Can you help?  (I can't explain why I didn't think about this when I reviewed -14; sorry.)

   Thus, in order to achieve
   any security benefit from certificate usage 0 or 1, an application
   that sends a request for TLSA records needs to get either a valid
   signed response containing TLSA records or verification that the
   domain is insecure or indeterminate.

There you define two criteria:
1. Get a valid signed response containing TLSA records.
2. Get verification that the domain is insecure or indeterminate.

   If a request for a TLSA record
   does not meet one of those two criteria but the application continues
   with the TLS handshake anyway, the application has gotten no benefit
   from TLSA and should not make any internal or external indication
   that TLSA was applied.

What indication might it make?  Are we just talking about audit logs of some sort?  In a user application, who will know or care about any indication that TLSA was applied?

In any case, this sentence seems to say that the application can get neither of  (1) or (2), and yet still continue with the TLS handshake.  It's advised not to set an indication that it's using TLSA, but that's not a MUST, and anyway it can go ahead with the handshake in any case.

   If an application has a configuration setting
   for turning on TLSA use, or has any indication that TLSA is in use
   (regardless of whether or not this is configurable), that application
   MUST not start a TLS connection or abort a TLS handshake if either of
   the two criteria above are not met.

That sentence confuses me, for a couple of reasons.  It seems contradictory to the prior sentence.  If you didn't get what you expect...

a. It says that if you have a configuration setting for TLSA, whether or not the setting is enabled, you have to abort.  I don't think that's what you mean.

b. It says that if you ignored the advice above and set your indication anyway, you MUST NOT [if you keep this, you need caps on the "not"] do stuff.  But the previous sentence said you could go ahead anyway.

c. The scope of the MUST NOT is wrong: it appears to say that you MUST NOT abort the TLS handshake, and I'm sure you don't mean that.

d. If *either* of the two are not met?  You mean if *both* are not met, because getting either is OK (and they're mutually exclusive).  Right?

-- 8.3 --
   For this reason, it is RECOMMENDED that DNSSEC validation always be
   performed on-host, even when a secure path to an external validator
   is available.

I found this odd, because at several earlier points you talked about using an external validator with a secure path, and this is the first mention that it's not advisable.  Please consider a reference to this section the first time you talk about that option (Sec 1.3), possibly in 4.1 after the bullet list, and also in Appendix A.3.


========
Other comments; no need to respond to these. Take them or modify them
as you please:

-- 2.1.2 --
   (Note that the use of "selector" in this document is completely
   unrelated to the use of "selector" in DKIM [RFC6376].)

Was there really confusion about that?  Wow.  DKIM also doesn't have anything to do with certificates.  Oh, well... no harm in mentioning this.

-- 8 --
   This in
   essence allows an intermediate CA to be come a trust anchor

Typo: "become" should be one word.

Last paragraph:
   While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may deny to trust the certificate (such as due to
   weak cryptography), the same as it is with PKIX trust anchors.

This is a really awkward sentence.  May I suggest this?:
NEW
   While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may decline to accept the certificate (for reasons such
   as weak cryptography), as is also the case with PKIX trust anchors.

(Sean Turner) (was No Objection, Discuss) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2012-06-14 for -22)
No email
send info
  Section 1.3 says:
  >
  > This document only applies to PKIX [RFC5280] certificates, not
  > certificates of other formats.  Later updates to this document might
  > specify how to use certificates in other formats.
  >
  I suggest that the second sentence be deleted.  Neither the TLS charter
  nor the DANE charter calls for support of new certificate formats.

  An informative reference to define "SSL proxy" would be very helpful.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Pete Resnick) Abstain

Comment (2012-06-06 for -21)
No email
send info
In general, I find section 3 wrongheaded. I think it was a poor design choice to use _port._protocol.rest.of.name. But a poor design choice is not a reason for a DISCUSS. However, I do think that the document should make *some* attempt to justify this poor design choice. Perhaps it's not a poor design choice at all and I'm all wet. But I'd like to hear an explanation. Section 1 says (emphasis mine, excerpted):

   TLS uses certificates to bind keys and *names*.

   The public CA model upon which TLS has depended is fundamentally
   vulnerable because it allows any of these CAs to issue a certificate
   for any *domain name*.

   The DNS Security Extensions (DNSSEC) provides a similar model that
   involves trusted keys signing the information for untrusted keys.
   However, DNSSEC provides three significant improvements.  Keys are
   tied to *names in the Domain Name System (DNS)*, rather than to
   arbitrary identifying strings; this is more convenient for Internet
   protocols.  Signed keys for any domain are accessible online through
   a straightforward query using the standard DNSSEC protocol, so there
   is no problem distributing the signed keys.  Most significantly, the
   keys associated with a *domain name* can only be signed by a key
   associated with the parent of that *domain name*; for example, the
   keys for "example.com" can only be signed by the keys for "com", and
   the keys for "com" can only be signed by the DNS root.  This prevents
   an untrustworthy signer from compromising anyone's keys except those
   in their *own subdomains*.

   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.  DANE is envisioned as a
   preferable basis for binding public keys to *DNS names*, because the
   entities that vouch for the binding of public key data to *DNS names*
   are the same entities responsible for managing the *DNS names* in
   question.

Nowhere does it say that any legacy use of the CA model, nor any designed use of the DANE model, is about anything but a biding between keys and *domain names*. Yet section 3 goes on to add the additional design requirement that I use a port *and* a transport to identify the TLSA record I'm looking for. That prevents me from having a single TLSA record for "www.example.com", which I suspect will be the widest use case, unless I try to do crazy things with wildcards or DNAMEs (and all of their associated pain) as described in Appendix A. There was a requirement in 6394 that "DANE should be able to support multiple application services with different credentials on the same named host, distinguished by port number", but nowhere does that say that it has to be done on the lookup side. (For example, it could be that multiple TLSA records exist for "www.example.com", but they are distinguishable from the data returned. If data size was the problem, you could have had the TLSA records point to a record that actually contained the cert data.) And nowhere does 6394 say that multiple *transports* is a requirement. Note that 6394 also gives wildcard use as a requirement, but that is barely met by this document in that I can't wildcard "all names", but rather I must create subdomains of "_tcp.example.com" and "_udp.example.com" and "_sctp.example.com" and put wildcards under there. Even then, that does not allow me to wildcard all possible transports which I currently don't know about.

So I think this was a terrible design choice. I don't think it reasonably satisfies the requirements of 6394. But a design choice it is. I do ask that you add some text justifying that design choice.