On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote:
> Section 2.2.2, Regarding the problem nameservers for
> largeemailprovider.com: If an insecure MX record is returned pointing
> to largeemailprovider.com, skip TLSA lookup, because even if we got a
> signed response, the insecure MX to the domain could have been
> MITM-ed. Makes sense.
That's not the point of 2.2.2, the specific provider dealt with in
2.2.2, which does not get named in the RFC, but was mentioned in
prior list discussion so the issue is more concrete is:
$ dig +adflag +noall +comment +ans -t mx nist.gov
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16582
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION:
nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com.
The MX record is in fact in a DNSSEC signed zone, and is secure,
what is not DNSSEC signed is:
$ dig +adflag +noall +comment +ans -t a nist-gov.mail.protection.outlook.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48597
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION:
nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.215
nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.247
nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.138
nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.170
Furthermore, TLSA lookups via recursive resolvers SERVFAIL:
$ dig +adflag +noall +comment +ans -t tlsa
_25._tcp.nist-gov.mail.protection.outlook.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36237
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
because, the authoritative nameservers are broken:
$ dig +norecur +adflag +noall +comment +ans -t tlsa
_25._tcp.nist-gov.mail.protection.outlook.com
@ns1-proddns.glbdns.o365filtering.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 54501
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> But I wonder if there might be a scenario where the insecure MX record
> appears to be insecure, but is not actually.
No, there is not.
> For example, if an admin specifically
> configures a mapping inside the smtpd (I think this is transport_maps
> in postfix?) - this type of mapping _could_ be labeled as 'secure'
A nexthop override is NOT an MX record and is considered secure,
it is locally specificied. Such a nexthop (with many MTAs) might
still be subject to MX records, and in that case, the security of
those MX records is what matters. I'm afraid you've got yourself
somewhat confused here...
This case is handled correctly both in Postfix and in the draft.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
