The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
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)
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)
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)
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.