In message <[email protected]>, Viktor Dukhovni writ
es:
> On Mon, May 25, 2015 at 08:31:23PM -0400, Paul Wouters wrote:
>
> > >If the A/AAAA is insecure the TLSA lookup will be insecure due to
> > >there being not DNSSEC trusted path the TLSA node.
> >
> > I don't understand this.
>
> Let's make it specific. If the zone containing
>
> smtp.example.com. IN A 192.0.2.1
>
> is unsigned (whether because example.com is unsigned, or because
> "smtp.example.com" is itself a delegated 'insecure' zone), then
> it is exceedingly unlikely (a miracle) if somehow the associated
> TLSA RRset:
>
> _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb924
> 27ae41e4649b934ca495991b7852b855
>
> is "secure". For that to happen, there would have to be an explicit
> DNSSEC trust-anchor for either "_tcp.smtp.example.com" or
> "_25._tcp.example.com" configured in the validating resolver.
>
> Since that's going to happen basically "never", the client just
> assumes the inevitable outcome, and avoids the lookup.
>
> The canonical problem case is "nist.gov". Their zone is signed
> and MX lookups yield a "secure" result:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52380
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> nist.gov. MX 0 nist-gov.mail.protection.outlook.com.
>
> If address record lookups that lead to "insecure" answers:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2284
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> nist-gov.mail.protection.outlook.com. A 207.46.163.247
> nist-gov.mail.protection.outlook.com. A 207.46.163.170
> nist-gov.mail.protection.outlook.com. A 207.46.163.138
>
> are not used to infer that "TLSA" is also "insecure" and thus to
> suppress TLSA lookups, then TLSA lookups fail, and to avoid
> "downgrade" attacks no mail is delivered to "nist.gov".
>
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60707
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA
The servers for outlook.com also don't handle EDNS version negotiation
or unknown EDNS options. ISC is intending to ship BIND 9.11.0 with
DNS COOKIES enabled by default. There is going to be more pain
than just TLSA lookups once that happens. See the following report
for all the EDNS compliance errors with the servers for outlook.com.
https://ednscomp.isc.org/ednscomp/6840acd09c
Yes, Microsoft were informed months ago that their servers are not
EDNS compliant and that what we intend to ship servers that won't
work with the servers they are using.
Fixing these bugs should take less than 5 minutes for a developer
of the nameservers Microsoft are using. They are trivial compliance
bugs.
Add:
/* If the EDNS version is != 0 send BADVERS as the error code. */
if (opt != NULL && ((opt->ttl >> 16) & 0xff) != 0) {
send_error(rcode = BADVERS);
return;
}
Remove:
if (opt != NULL && opt->rdlen != 0) {
send_error(rcode = FORMERR);
return;
}
As unknown EDNS options are supposed to be ignored.
Reconfigure the firewall to ignore EDNS version in the opt record
on 3 of the servers.
Fixing the TLSA issue is also similar. It should result in a NOERROR
no data response. Stop sending NOTIMP on unknown types that are
not reserved for META queries. The handling of non meta query types
was documented over a decade ago. The servers are capable of sending
valid NOERROR no data responses which this mx response demonstrates.
; <<>> DiG 9.11.0pre-alpha <<>> +noedns mx
_25._tcp.nist-gov.mail.protection.outlook.com
@ns2-proddns.glbdns.o365filtering.com +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56970
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;_25._tcp.nist-gov.mail.protection.outlook.com. IN MX
;; AUTHORITY SECTION:
mail.protection.outlook.com. 3600 IN SOA
ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801
3600 600 86400 3600
;; Query time: 188 msec
;; SERVER: 207.46.100.42#53(207.46.100.42)
;; WHEN: Tue May 26 12:13:19 EST 2015
;; MSG SIZE rcvd: 190
It's not like sending the wrong response code is a new issue. We
have CERT advisories issued in the past for just such misbehaviour
(NXDOMAIN in response to AAAA queries).
Is it going to require someone writing up a CERT advisary for load
balancer vendors to fix their broken servers?
> Such failures would make deployment of DANE TLS for SMTP unattractive
> to MTA administrators. The proposed language (implemented in
> Postfix and Exim) avoids this problem. We've discussed this before.
>
> > Wether the A/AAA is spoofed or someone
> > with sufficient power to redirect routing of that range to them
> > is the same thing.
>
> The A/AAAA lookups serve to discover whether the zone with the
> server name is signed. We don't actually care whether the address
> records are secure. We could query for any other record that
> "bare-bones" nameservers don't mishandle, but since the A
> records will be needed anyway, we use those.
>
> > I don't like that because I would like to be able to publish TLSA
> > records in my nohats.ca zone pointing to some mail service I use
> > that uses certificates but are not themselves dnssec signed. eg:
> >
> > nohats.ca. IN MX 5 mail.insecure-bigmail.com.
> > nohats.ca. IN TLSA <blob>
>
> This does you no good anyway, because queries for TLSA records with
> MX and SRV services are made for the "_<port>._tcp.<target host>"
> NOT "_<port>._tcp.<service domain>". Nor are you particulary likely
> to reliably publish accurate TLSA records for a server operated by
> a third party. Inevitably they'll make changes on their end, and
> your mail will stop. So this is not an option.
>
> > As for insecure TLSA records themselves, while I would prefer we
> > would use them in a better-than-nothing sense, I am more fearful of
> > implementations just not bothering or forgetting to check for DNSSEC
> > and blindly trusting these. So I think it is more clear to just say
> > ignore insecure TLSA records.
>
> I think we agree on that.
>
> --
> Viktor.
>
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
