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
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
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
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
