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.
