The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
draft-ietf-dane-protocol-23

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.