On 2/22/19 10:43 AM, Yaron Sheffer wrote: > Reviewer: Yaron Sheffer > Review result: Has Nits > > [Apologies for the late review.] [And for the late response.] > > * Intro: To avoid confusion, please mention the header parameter "No" to > clarify why the header is named RequireTLS when its semantics is the exact > opposite, "prioritize delivery over ability to negotiate TLS"? The same > confusion already arises in the abstract. OK. > * Sec. 2: it seems to be implied that > when REQUIRETLS is used, STARTTLS MUST also be sent. Is this the case? If so, > please mention it (it's obvious to you but not to a first time reader). STARTTLS is normally needed, but wouldn't be if implicit TLS (i.e., on submission port 465) is used. > * 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. 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. I am sure you've already beaten this horse to death, but if you have not, > I think this is a real issue. The thing is, if ever we have widespread > deployment of DANE (which I do NOT expect), this mechanism will not be as > secure as it could have been. In earlier drafts, the REQUIRETLS SMTP parameter had options that allowed the sender to specify whether DANE or certificate chain verification of certificates (or either) should be used. That isn't exactly the same as what you're suggesting, but it's close. The WG consensus was to eliminate the option because it was considered to be unnecessarily complex. > * 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. Pre-negotiation of TLS or STARTTLS can be used with submission, and REQUIRETLS can be specified at submission. There is no standard port for MTA-to-MTA use. > * RequireTLS header field: I believe that the REQUIRETLS > parameter MUST NOT be used when the header field is there, why not mention it? We have gotten other comments that this case should throw an error. We will probably be doing this. > * 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? Alexey is researching this. > * The > word "no" appears twice in Sec. 3, capitalized as "NO" or "No". Are parameters > case insensitive? Yes. > * The case of REQUIRETLS+RequireTLS on receipt is > interesting, and the MAY requirement (Sec. 4.1) makes it non-deterministic. Why > don't we simply disallow it and reject the message? See above; this will probably be disallowed and cause it to throw an error. > * The textual name is > mentioned twice, once with and once without a space. Will be corrected. > * 8.2 (active attacks): > this solution is still vulnerable to the DNS blocking attack associated with > MTA-STS (RFC 8461, Sec. 10.2), and this should be mentioned here. If the REQUIRETLS SMTP option is used, either MTA-STS or DNSSEC confirmation of the MX host is required. If DNS is blocked (and DNSSEC is not used), transmission of messages requiring TLS fail. So I would consider REQUIRETLS to be less vulnerable to that attack than MTA-STS by itself, except possibly as a denial-of-service attack on REQUIRETLS-tagged messages. There are much better ways to DOS a mail server than this. Does it warrant mentioning? Thanks for your review. -Jim
