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

[Jim Fenton <[e-mail]>]

On 8/23/18 6:49 PM, Viktor Dukhovni wrote:
>
>> On Jul 18, 2018, at 1:50 PM, Valery Smyslov <[e-mail]> 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.

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?

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

It looks like I got the correct reference there.

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

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