Subject: Re: [Uta] Last call: <draft-ietf-uta-smtp-require-tls-03> "SMTP Require TLS Option"

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Aug 2018 21:49:27 -0400

> On Jul 18, 2018, at 1:50 PM, Valery Smyslov <[email-masked]> wrote:
> 
> draft-ietf-uta-smtp-require-tls-03

In https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-03#section-4.2.1
bullet 3, the reference to DANE authentication is to RFC6698, but DANE for SMTP
is defined in RFC7672.  The RFC6125 reference as an alternative may not be a
sufficient alternative to DANE, since absent one of DANE or MTA-STS (and in the
absence of DNSSEC validation of the MX lookup) the protocol is vulnerable to DNS
forgery of the MX hostname.

The same issue re non-DANE authentication is also in Section 2:

     o  The certificate presented by the SMTP server MUST either verify
      successfully in a trust chain leading to a certificate trusted by
      the SMTP client or it MUST verify succesfully using DANE as
      specified in RFC 7672 [RFC7672].  For trust chains, the choice of
      trusted (root) certificates is at the discretion of the SMTP
      client.

In this document MTA-STS seems to only be mentioned as policy source to
ignore with "RequireTLS: NO", but not as the alternative authentication
mechanism when DANE is not available.

This is recognized in the Security Considerations:

   Another active attack involves the spoofing of DNS MX records of the
   recipient domain.  An attacker having this capability could cause the
   message to be redirected to a mail server under the attacker's own
   control, which would presumably have a valid certificate.  REQUIRETLS
   does not address this attack.

Might it not make sense to close this hole and require one of MTA-STS
or DANE?  This delays the practical deployment of REQUIRETLS (yes) to
such time as at least of one MTA-STS or DANE is generally present, but
I think this is better than leaving the above security gap unaddressed.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Aug 2018 10:58:19 -0700

> forgery of the MX hostname.

It looks like RFC7672 is the more appropriate reference to cite, so 
thanks for that correction. I don't understand what MTA-STS has to do 
with this, though; isn't it only DNSSEC validation of the MX lookup that 
matters as far as forgery of the MX hostname is concerned?

>        trusted (root) certificates is at the discretion of the SMTP

It looks like I got the correct reference there.

> mechanism when DANE is not available.

DANE is mentioned as one of the policy mechanisms in the introduction 
(paragraph 2), but the text in Section 3 only says "policy-based 
mechanisms", and I agree that it would be clearer to enumerate them.

Of course, underlying DNSSEC failures in the MX lookup will be difficult 
to ignore, since verifying resolvers will just return a SERVERR rather 
than the address of the MX record. I'm not aware of any API hooks that 
force the resolver to ignore this. Is there any?
> I think this is better than leaving the above security gap unaddressed.
An important class of attacks involves only interference with STARTTLS 
negotiation [1]; there is a wide variety of off-the-shelf commercial 
products that provide this capability. It would be beneficial to provide 
protection against these attacks even if REQUIRETLS doesn't protect 
against DNS spoofing, and I am concerned that requiring DNSSEC (by both 
the MX record's zone and the resolver the client uses to retrieve it) 
would delay this benefit for an unacceptably long time. Of course, I 
think that the better approach is to provide a REQUIRETLS option to 
allow the client to require DNSSEC where it is expected to work, but the 
WG has asked me to remove that.

-Jim

[1] Durumeric, Zakir, J. Alex Halderman, David Adrian, Ariana Mirian, 
James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay 
Eranti, and Michael Bailey. “Neither Snow Nor Rain Nor MITM...: An 
Empirical Analysis of Email Delivery Security,” 27–39. ACM Press, 2015. 
https://doi.org/10.1145/2815675.2815695.