Ballot for draft-ietf-dane-smtp-with-dane
Yes
No Objection
Note: This ballot was opened for revision 17 and is now closed.
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.