SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
draft-ietf-dane-smtp-with-dane-19

References and terminology:
You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and "MUA".  And these are definitions that must be understood in order to properly understand this document.  I think that makes those normative references, not informative ones, and they should be changed.  (5598 is already in the downref registry, so,there's no problem with the downref here.)

>> Author will move the references.


In Section 2.2.1:

   When DANE TLS is mandatory (Section 6) for
   a given destination, delivery MUST be delayed when the MX RRSet is
   not "secure".

This contradicts the "delivery MAY proceed" in the previous paragraph (and it also doesn't really fit into the paragraph about logging anyway).  If you want to restrict things, I think you should put the most restrictive condition first, so move this sentence to the top of the previous paragraph.

>> Author will make this change:

OLD
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
   pre-DANE opportunistic TLS.
NEW
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), then if DANE TLS is mandatory (Section 6) for
   the given destination, delivery MUST be delayed.  If DANE TLS
   is not mandatory, then DANE does not apply and delivery proceeds
   with pre-DANE opportunistic TLS (perhaps even in cleartext).
END

-- Section 2.2 --

   contrast, DNSSEC validated TLSA records MUST NOT be published for
   servers that do not support TLS.  Clients can safely interpret their
   presence as a commitment by the server operator to implement TLS and
   STARTTLS.

I don't know that this needs any text changes, though perhaps a mention of this in the Security Considerations would be good: I'm not sure how "safely" they will be able to do that in practice.  Remember that the people running the email severs often have no connection to the people who will insert or remove the TLSA records from the DNS.  It's possible that a software change in the mail servers will remove support for DANE, and the TLSA record will not be correspondingly removed.

I'm hoping that once this really gets rolled out, that won't be a real issue, but it could be for a while.  It might be worth saying in the Security Considerations that such a situation needs to be avoided, and coordination is important, to make sure it doesn't happen.  Otherwise, according to Section 2.2, mail delivery from DANE-aware MTAs will fail.

>> Author will decide here -- probably not necessary to change anything: already sufficiently obvious.


>> Author agrees with all of the following, and will adjust the text appropriately:

-- Sections 2.2.1 and 2.2.2 --

In 2.2.1:
   In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
   is not "insecure" then it is "secure", and the SMTP client MUST treat
   each MX hostname as a separate non-MX destination for opportunistic
   DANE TLS (as described in Section 2.2.2).

In 2.2.2:
   This section describes the algorithm used to locate the TLSA records
   and associated TLSA base domain for an input domain that is not
   subject to MX resolution or that lacks MX records.

I find this combination unnecessarily confusing -- it starts to sound a bit like Fizzbin <http://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin>.  I know it's explained further (which is why this isn't a DISCUSS point), but I think clarity in the introduction would help a lot.  I suggest this, but anything similar would be equally helpful:

NEW
   In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
   is not "insecure" then it is "secure", and the SMTP client MUST treat
   each MX hostname as described in Section 2.2.2.
END

NEW
   This section describes the algorithm used to locate the TLSA records
   and associated TLSA base domain for an input domain that is not
   subject to MX resolution, that represents a hostname from a secure MX
   RRset, or that lacks MX records.
END

That latter ordering matches the order of the bullet list, and I think that's useful for making the text understandable.  You might also re-think the title for Section 2.2.2, but I think that's less important.

-- Section 2.2.3 --

   If the ultimate response is a "secure" TLSA RRSet, then the candidate
   TLSA base domain will be the actual TLSA base domain and the TLSA
   RRSet will constitute the TLSA records for the destination.  If none
   of the candidate TLSA base domains yield "secure" TLSA records then
   delivery MAY proceed via pre-DANE opportunistic TLS.  SMTP clients
   MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
   or even to skip SMTP servers that fail authentication, but MUST NOT
   misrepresent authentication success as either a secure connection to
   the SMTP server or as a secure delivery to the intended next-hop
   domain.

When SMTP clients elect to use insecure TLSA records, this text implies, but doesn't make it completely clear, that they should only do that after checking all candidates.  It would be good to be clear: check all candidates, stopping at the first secure TLSA.  If no candidates produce secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE TLS.  Is that right?

In general, I strongly encourage you to review Section 2.2.3 and make sure that it reads smoothly to someone who's not already familiar with the DANE SMTP work.  I'm not sure the organization of the thoughts in this section is very good as it's currently written.

-- Section 3.1 --

   In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1)
   SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
   depending on site needs.

But later, in Section 3.1.1, you specifically single out the former:

   TLSA records published for SMTP servers SHOULD, in most cases, be
   "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

To be more consistent in your advice, I suggest changing the advice in 3.1 thus:

NEW
   In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1)
   SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA
   records as a second choice, depending on site needs. See
   the following two subsections for more details.
END

If that's not the advice you mean to give, then something is unclear.

-- Section 3.1.1 --

   Similarly, the expiration date of the server certificate MUST be
   ignored, the validity period of the TLSA record key binding is
   determined by the validity interval of the TLSA record DNSSEC
   signature.

Editorial: "Similarly" to what?  I'd remove the word.  Also, the comma after "ignored" needs to be a colon (or a semicolon, but I think a colon is better here; the comma splice is just wrong).

   With DANE-EE(3) servers need not employ SNI (may ignore the client's
   SNI message) even when the server is known under independent names

Editorial: This needs a comma after "DANE-EE(3)", and would do well with "they" before "may ignore").

-- Section 3.1.1 --

   Such servers MUST either publish DANE-TA(2)
   records for an intermediate certificate or MUST instead use DANE-
   EE(3) TLSA records.

The first "MUST" should be moved one word later, after "either" (or else the second "MUST" should be removed).

-- Section 3.1.3 --

   Note, this section applies to MTA-to-MTA SMTP on port 25.

Earlier, in 2.2.3, you note that "the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator".  I don't think you mean for this section not to apply in the latter case, so I suggest changing this to, "Note, this section applies to MTA-to-MTA SMTP, which is normally on port 25."

   Nothing is lost since the
   PKIX certificate usages cannot aid SMTP TLS security, they can only
   impede SMTP TLS interoperability.

Editorial: You need a comma after "lost", and the existing comma needs to be a semicolon.

The last paragraph of the section is missing a final period.

-- Section 6 --

   Administrators of mail servers that employ mandatory DANE TLS, need
   to carefully monitor their mail logs and queues.

Nit: the comma should be removed.

Thanks for this. I only have a few trivial comments:

 2.1.3, first paragraph:

The seems redundant to similar normative language in 2.1.1

2.1.3, last paragraph: "...it may need to issue a
   separate query..."

I assume that means it also may _not_ need to do so. Is it worth elaborating on that case?

Editorial:

2.3.3, first sentence: This is pretty convoluted. You might consider breaking it into a few simpler sentences.