> On Apr 25, 2017, at 10:22 AM, Jeremy Harris <jgh@???> wrote:
>
> On 25/04/17 14:51, Viktor Dukhovni wrote:
>> I might also mention that Exim's DANE support is not yet feature-complete.
>> It is still vulnerable to active downgrade attacks by tampering with the
>> TLSA RRset in DNS responses. When TLSA lookups fail, Exim continues without
>> DANE, while RFC7672 explains that DANE clients need to skip the associated
>> MX host in that case in order to avoid downgrade attacks.
>
> How many of the set of MXs should that suggestion be applied to?
TLSA record lookups are performed one MX host at a time, after
determining that the MX host has a secure (DNSSEC validated)
A or AAAA RRset. For each and every such MX host (with validated
A/AAAA records), if the TLSA lookup fails to conclusively determine
whether TLSA records exist or not, the MX host is skipped in order
to avoid downgrade attacks.
As explained in
https://tools.ietf.org/html/rfc7672#section-2.1,
NXDOMAIN is not (such) a failure, you learn that there are no
TLSA records, which is fine. Failure is "SERVFAIL", "timeout",
validation error (but with Exim asking the local resolver, "bogus"
DNSSEC replies are morphed into "SERVFAIL").
> If "all", how should the MTA distinguish the situation from
> "there really were no TLSAs, and the responding DNS is faulty"?
You can't distinguish active attacks from service failure. If
the DNS is broken you defer delivery until the DNS is fixed.
Otherwise instead of "STARTTLS stripping" you get "TLSA +
STARTTLS stripping" and we're back where we started.
Fortunately, DNSSEC TLSA record lookup problems are quite
rare. Of 3.4 million DNSSEC domains scanned, only ~260
exhibit problems with TLSA lookup.
As more sending systems deploy DANE outbound, receiving systems
will learn to keep their DNS monitored and working, in order to
avoid email delays.
--
Viktor.
