On Fri, Feb 22, 2019 at 10:43:34AM -0800, Yaron Sheffer wrote: > I would have expected a parameter to be associated with REQUIRETLS to indicate > whether DANE is required throughout the forwarding path, or MTA-STS, or either > one will do. Leaving the security mechanism unspecified was a deliberate choice discussed in the WG. The "REQUIRETLS = yes" case is fragile enough as is, without the user imposing fine-grained constraints on the security mechanisms available on all the MTAs along the delivery path. > Although RFC 8461 takes care to not use the "opportunistic" word, > it is in fact opportunistic to some degree (because an attacker can block the > initial policy lookup with DNS) and so has different security properties than > DANE. Yes, and by theh way "opportunistic security" (RFC7435) does not mean "weak" or "unauthenticated", it just means not required a-priori at the origin, and so applied on a case by case basis based on discovered peer capabilities. In the case of DANE the policy discovery mechanism is resistant to downgrades at first contact, and in the case of MTA-STS it is not. And yet, despite my obvious enthusiasm for DANE, I don't think it is (at least in the near-term) realistic for users to require DANE along the entire path beyond what might happen naturally because some of the receiving systems publish TLSA records and the sending system supports DANE. > I am sure you've already beaten this horse to death, but if you have not, > I think this is a real issue. Yes, this was discussed. > The thing is, if ever we have widespread deployment of DANE (which I do NOT expect), It is not about to happen for HTTPS any time soon, but much progress has happened in that direction on the SMTP front. Out of over 9.3 million DNSSEC domains surveyed (out of an estimated ~10 million world-wide total), there are 1.07 million DANE-enabled domains. Momentum is building in Northern Europe, but the U.S. has the second highest number of DANE MX hosts by GeoIP after Germany. Also mx[1-4].smtp.goog are DNSSEC signed, and could easily have TLSA records which makes DANE possible for over 500k DNSSEC-signed domains MX-hosted by Google, if they update their MX RRset to point to these hostnames (signed aliases for the usual Google MX hosts). I would not surprised to see Google actually publish the TLSA records some time in the next 12 months. > this mechanism will not be as secure as it could have been. It won't be secure at all, if it never gets used, and making it overly specific reduces the already marginal usability. * Sec. 2 security requirements: the session must > employ TLS: does this include pre-negotiation of TLS before starting SMTP, or > only session upgrade with STARTTLS? This is common in Submission, I'm not sure > about MTA-to-MTA use. (MTA-to-MTA) SMTP *only* uses STARTTLS. "Implicit TLS" is only for SUBMIT and IMAP. > * RequireTLS header field: I believe that the REQUIRETLS > parameter MUST NOT be used when the header field is there, why not mention it? This is certainly a reasonably observation. > * If we define a case where MTA-STS policy is to be ignored (when using > RequireTLS: No), shouldn't this document be marked as Updates RFC 8461? IMHO that's just local policy. -- Viktor.
