Subject: Secdir last call review of draft-ietf-uta-smtp-require-tls-07

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Feb 2019 10:43:34 -0800

Reviewer: Yaron Sheffer
Review result: Has Nits

[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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Feb 2019 17:31:57 -0500

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
> 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,
> 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
> 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

This is certainly a reasonably observation.

> RequireTLS: No), shouldn't this document be marked as Updates RFC 8461?

IMHO that's just local policy.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 15:19:28 -0800

> [Apologies for the late review.]
[And for the late response.]
> confusion already arises in the abstract.
OK.
> * Sec. 2: it seems to be implied that
> 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
> 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.

> only session upgrade with STARTTLS? This is common in Submission, I'm not sure

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.

> 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.

> RequireTLS: No), shouldn't this document be marked as Updates RFC 8461?

Alexey is researching this.

> * The
> case insensitive? 

Yes.

> * The case of REQUIRETLS+RequireTLS on receipt is
> 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):

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