Skip to main content

Last Call Review of draft-ietf-uta-smtp-require-tls-07
review-ietf-uta-smtp-require-tls-07-secdir-lc-sheffer-2019-02-22-00

Request Review of draft-ietf-uta-smtp-require-tls
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-02-08
Requested 2019-01-25
Authors Jim Fenton
I-D last updated 2019-02-22
Completed reviews Secdir Last Call review of -07 by Yaron Sheffer (diff)
Genart Last Call review of -07 by Peter E. Yee (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Request Last Call review on draft-ietf-uta-smtp-require-tls by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 09)
Result Has nits
Completed 2019-02-22
review-ietf-uta-smtp-require-tls-07-secdir-lc-sheffer-2019-02-22-00
[Apologies for the late review.]

* 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. * 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). * 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. * 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. * RequireTLS header field: I believe that the REQUIRETLS
parameter MUST NOT be used when the header field is there, why not mention it?
* 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? * The
word "no" appears twice in Sec. 3, capitalized as "NO" or "No". Are parameters
case insensitive? * 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? * The textual name is
mentioned twice, once with and once without a space. * 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.