Quick response for tonight, with a fuller one on Tuesday, NY time: Thanks for the responses, Viktor and Olafur. Between the two, you've explained what I need for DISCUSS point 2. Tomorrow I'll clear the DISCUSS completely and give a better email response (short version: all is good on all comments, and thanks).
As to when to post a revised I-D: my preference is always "early and often", but you should check with Stephen, as he's the responsible AD. Barry On Sun, May 24, 2015 at 10:04 PM, Viktor Dukhovni <[email protected]> wrote: > On Sun, May 24, 2015 at 01:41:21PM -0700, Barry Leiba wrote: > >> 1. 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.) > > No objections from me. If nobody else objects, I'll move these to > normative in a few days. > >> 2. Section 2.2.1 says this: >> >> That said, the protocol in this memo is >> an "opportunistic security" protocol, meaning that it strives to >> communicate with each peer as securely as possible, while maintaining >> broad interoperability.? Therefore, the SMTP client MAY proceed to >> use DANE TLS (as described in Section 2.2.2 below) even with MX hosts >> obtained via an "insecure" MX RRSet.? For example, when a hosting >> provider has a signed DNS zone and publishes TLSA records for its >> SMTP servers, hosted domains that are not signed may still benefit >> from the provider's TLSA records. >> >> That makes sense. Why doesn't the same thing apply for insecure TLSA >> records? Section 2.2 says that when TLSA records are insecure, you don't >> use them, and SHOULD use pre-DANE security. Please explain why they >> shouldn't use insecure TLSA records for opportunistic encryption. > > If I recall correctly, the working group was concerned about diluting > the otherwise clear position that TLSA should not be used without > DNSSEC. > > In the context this draft alone, the main reason to avoid using > TLSA records from insecure zones, is that lookups of such records > are prone to failures (with long timeouts while trying all NS > records) against "bare-bones" nameservers that support neither > DNSSEC nor TLSA records. > > When the MX RRset is secure, but the A/AAAA records are insecure, > no TLSA lookup takes place. I think that proceeding with (soft-fail) > TLSA lookups when the MX RRset is insecure invites implementation > errors. > >> 3. 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 this way: >> >> 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 it need not apply, and delivery MAY proceed >> via pre-DANE opportunistic TLS. >> END > > Thanks, this is a big improvement. Perhaps the "MAY proceed" should > probably also be clarified. The intention is to note the possibility > of using pre-DANE TLS (which is not required, cleartext is also > allowed). It is not the intention of this text to make using the > MX host optional. Delivery, with or without TLS, MUST be attempted. > > So perhaps better still: > > 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 -- >> >> ... 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. > > Indeed the "safely" is the result of the server mandate, and also the > problems servers will incur when they mess up, once this protocol is > adopted sufficiently widely. So "safely" is somewhat forward-looking. > Should such a note be in "Security" or "Operational" considerations? > And is it really needed? > >> 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. > > We're on the same page, the only question is whether this is > sufficiently obvious to avoid needing to explain it. > >> -- 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. >> >> 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 > > Much better, thanks. When would you like to see a new version with > these changes? (I am guessing I should wait for any additional IESG > comments?) > >> You might also >> re-think the title for Section 2.2.2, but I think that's less important. > > I see what you mean, but nothing obvious comes to mind. Is "Post-MX" > better than "Non-MX"? > >> -- 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. > > Thanks for highlighting this. The same fix as above for "MAY > proceed via pre-DANE opportunistic TLS" should likely be applied > here. > >> 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. > > Yes. There are at most two choices (before and after CNAME > expansion). The expansion is tried first, and if that is not > secure, and there was in fact CNAME indirection, the origin MUST > be tried. If the origin is secure, that MUST be used. > > I can tweak this text for more clarity. > >> 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? > > Yes, and that "last" MAY, is really a "free to use TLS the old > way", but in any case MUST use the destination with whatever security > you can get. No skipping of insecure MX hosts. Adherence to MX > preference first, channel security second. > >> 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. > > Noted. How should I communicate any proposed revisions? > >> -- 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. > > Indeed, these two are a sufficient best-practice set to cover all > 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. > > The vast majority of sites should (and do in fact among the early > adopters) stick to usage DANE-EE(3), the DANE-TA(2) case is for > select sites with an internal PKI (private CA) and lots of servers. > >> 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 > > This works. Thanks. > >> -- 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). > > Will do. > >> 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"). > > Thanks. > >> -- 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). > > Thanks, no problem. > >> -- 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." > > Thanks. Indeed that's the correct formulation. > >> 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. > > No worries. > >> -- 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. > > -- > Viktor. > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
