Time for a proper reply now. I've already cleared the DISCUSS and recorded the resolution in the tracker comments, but I didn't have it re-send the message (this will serve for that). I'm adding the IESG list back to the CC on this reply. Anything I don't mention is stuff we agree on that needs no further comment. And thanks for considering all my comments and addressing them.
>> 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. Olafur further adds: > Barry, the working went down this path at one point and it turns quickly into > a quicksand of special cases. For that reason we are not in base documents > allowing TLSA w/o DNSSEC, Same goes for Service Records (SRV + MX) > as if those are forged there is no value in TLSA for the forged servers. > IMHO we should hold SRV and MX records to the same standard and IESG > has blessed the SRV doc with DNSSEC MUST, so I will object strongly to > any attempt to lower the requirements. I'm happy with the explanation (and that the issue was discussed by the working group, so I've removed this comment entirely. Thanks for the discussion. >> 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 Yes, that looks great, so keep that one. Thanks for further tweaking it. >> -- 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. You're probably right, and this is entirely up to your judgment. If you see anything you think is worth adding, fine; if not, that's also fine. >> 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"? Hm. Yes, perhaps. Again, to your judgment on this, including not making any change if that's what you think best. >> 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. Thanks... whatever you decide will be fine. >> 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? No need to communicate them explicitly: I trust you to review it and do what you can to organize it. This was (and is) a non-blocking comment. Thanks in advance for giving it another look. Barry _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
