On 8/23/18 6:49 PM, Viktor Dukhovni wrote:
On Jul 18, 2018, at 1:50 PM, Valery Smyslov <[email protected]> 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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
