Hi, On the flight to Singapore, I went through the latest mta-sts draft, and have a number of comments. Some of these I have probably made before, but (at the risk of belaboring old items) I think they warrant revisiting.
My overarching concern is whether MTA-STS would be effective against an attacker that is able to mount a downgrade or man-in-the-middle attack on STARTTLS. An attacker that is positioned between mail servers to be able to block the negotiation of STARTTLS probably is also positioned to be able to block the _mta-sts TXT record response, making it look like there's no policy. - In the introduction, it lists as one of the goals countering attacks by those who can overwrite the resolved MX record of the delivery domain. This is a good goal, and largely addressed by verifying certificates, but if DNS attacks are on the table, we need to talk more about attackers who can block the mta-sts TXT record (see below). - 2. Related technologies: I wouldn't describe as "upgrading plaintext transmission" -- if STARTTLS couldn't be negotiated, it still won't. Suggest upgrade -> inhibit - Section 2 paragraph 2 makes it sound like DANE does reporting, and it doesn't. This should refer instead to relevant stuff in tlsrpt. - Section 3.2 "mode" key/value pair: What does "report" do now that tlsrpt is separate? It seems like the modes now ought to be "enforce" and "none". - max_age: Does expiration of max_age trigger a refresh or does it simply age out of the cache? I had thought that TXT record suppresion attacks were mitigated by only requiring the TXT record initially, but this makes it sound like it ages out and has to be rediscovered the next time a message is sent to the domain. The paragraph also encourages use of very long max_age values to mitigate attacks at policy refresh time; what sorts of attacks are anticipated? Just to be clear, I do not consider use of long cache times to be an effective security measure. - Section 3.3: Does certificate expiration constrain the max_age of a cached policy? (if the certificate expires very soon) - Section 3.4: #Policy Validation section header looks like an unconverted section header from Markdown. - Section #Policy Validation: "does not dictate the behavior of sending MTAs when policies fail to validate" but following the semicolon it says that "report" or "none" MUST NOT be interpreted as delivery failures, which seems like exactly that. Suggest removing "in particular" and everything before it in the sentence. - Section 3.5 paragraph 3: Mangled reference to RFC 6125. - Section 4 "enforce" prohibits delivering when things fail mta-sts, but Section 2 says, "MTA-STS is designed not to interfere with DANE deployments where the two overlap". Doesn't this requirement constitute that sort of interference? - Section 4 "report": delete? (because this is in tlsrpt) - Section 6.1: Why is SNI always required? Can't a small MTA that only ever serves one domain get by without it? - Section 7.1 leads me to question the benefit of having a policy ID in the TXT record as opposed to just a hint whether might be a MTA-STS policy. Apparently the only time the a sender i. required to check the TXT record is when they don't have a policy (first message or it has expired). Of course senders could check TXT more often but I don't see any guidance for that. With the record being checked on max_age expiration (assuming it doesn't just age out, see question above) and max_age being expressed in weeks, the number of HTTPS transactions saved is going to be small. Balance that against the added operational complexity of having to update both DNS and the policy server when the policy changes. - Section 7.2 paragraph 3: Suggest "a host" -> "an address" - Section 7.3 item 2: This could also be simpler if there is no policy ID; in any case it's not clear what triggers retrieval of the TXT record if the sender already thinks it knows a policy for recipient domain. - Section 9.2 paragraph 1 refers to a "victim sending domain" and 9.3 paragraph 2 refers to a "victim domain" that is apparently the domain setting up an MTA-STS policy. This terminology needs to be more consistent. Perhaps avoid use the word "victim" at all (although it would be good to better understand who benefits from publishing MTA-STS). - Sections 11 and 12 should be real appendices; xml2rfc can do this. Should also be marked informative in case there is an inconsistency with the spec. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
