Re: [exim-dev] DANE

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Viktor Dukhovni
Datum:  
To: exim-dev
Betreff: Re: [exim-dev] DANE
On Wed, Apr 20, 2016 at 06:59:15PM +0100, Jeremy Harris wrote:

> >>>   * TLSA record lookup failures are not handled correctly.
> >>>     If the host's A records are signed,

> >>
> >> Signed in what fashion?
> >
> > I should perhaps have said "DNSSEC validated", that is that the A
> > records are in a "signed zone".
> >
> >>>     then TLSA record lookup
> >>>     failure must block connections to the host, whether dane is
> >>>     "required" or not.  On the other hand, insecure TLSA records,
> >>>     (CNAME to insecure zone perhaps) should simply be ignored.

>
> You want to enforce that DANE is used any place DNSSEC is used?


No of course not. Lookup failure is not the same as NXDOMAIN (which
is not a failure), see RFC762 Sections 2.1.1 and 2.1.2.

> Perhaps I misunderstand; this does not seem viable.


I am not that silly. To defend against downgrade attacks, an SMTP
client that implements DANE needs to defer (or skip to the next MX
host) delivery when TLSA lookup fails:

    * times out
    * an RCODE other than NOERROR or NXDOMAIN is received,
      e.g. SERVFAIL
    * a BOGUS response is received.


Fortunately, in both Postfix and Exim the heavy-lifting is done by
the local validating resolver and the stub resolver in the C library.
All that remains to be done in application code is to distinguish
between the following cases:

    * Got TLSA records with AD=1 => try to use them
    * Got TLSA records with AD=0 => feel free to ignore them
    * Got no TLSA records => deliver normally unless DANE is required
    * Got a lookup error => skip MX host, try next or defer


Thus for the usual h_errno values:

     #define NETDB_SUCCESS  0 /* no problem */
     #define HOST_NOT_FOUND 1 /* Authoritative Answer Host not found */
     #define TRY_AGAIN      2 /* Non-Authoritative not found, or SERVFAIL */
     #define NO_RECOVERY    3 /* Non-Recoverable: FORMERR, REFUSED, NOTIMP */
     #define NO_DATA        4 /* Valid name, no data for requested type */


errors (non-zero) other that NO_DATA(4) or HOST_NOT_FOUND(1) are
potential downgrade attacks and need to cause the MX host to be
skipped.

A key complication is described in Section 2.2.2 of RFC 7672, some
(mostly mail.protection.outlook.com) nameservers always fail TLSA
lookups. However, these servers are not DNSSEC-capable and serve
insecure A/AAAA records.

So the recommended work-around is to not ask for TLSA records of
hosts whose A records are insecure.

A key example is nist.gov:

    $ dig +ad +noall +comment +qu +ans +nocl +nottl -t mx nist.gov.
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ;nist.gov.        IN MX
    nist.gov.        MX    0 nist-gov.mail.protection.outlook.com.


    $ dig +ad +noall +comment +qu +auth +nocl +nottl -t soa nist-gov.mail.protection.outlook.com.
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    ;nist-gov.mail.protection.outlook.com. IN SOA
    mail.protection.outlook.com. SOA ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 3600 600 86400 3600


    $ dig +ad +noall +comment +qu +ans +auth +nocl +nottl -t ns mail.protection.outlook.com.
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;mail.protection.outlook.com. IN    NS
    mail.protection.outlook.com. NS    ns1-proddns.glbdns.o365filtering.com.
    mail.protection.outlook.com. NS    ns2-proddns.glbdns.o365filtering.com.


    $ dig +norecur +noedns +ad +noall +comment +qu +ans +nocl +nottl -t A nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com.
    ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
    ;nist-gov.mail.protection.outlook.com. IN A
    nist-gov.mail.protection.outlook.com. A    207.46.163.170
    nist-gov.mail.protection.outlook.com. A    207.46.163.138
    nist-gov.mail.protection.outlook.com. A    207.46.163.247


    $ dig +norecur +noedns +ad +noall +comment +qu +ans +auth +nocl +nottl -t TLSA _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 332
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA


Note the completely inappropriate NOTIMP in the TLSA lookup response!
Changing the RRtype to "A" for the same name correctly yields NXDOMAIN:

    $ dig +norecur +noedns +ad +noall +comment +qu +ans +auth +nocl +nottl -t A _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13191
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;_25._tcp.nist-gov.mail.protection.outlook.com. IN A


So this nameserver is busted, but servs many tens of thousands of
domains, the work-around is to not ask, because the zone is unsigned,
as evidenced by the missing "ad" bit in the "A" record lookup for
the MX hostname.

-- 
    Viktor.