On 23 Aug 2015, at 20:18, Paul Wouters wrote: >> Unsigned RRSET contain: >> >> example.net. IN MX 0 mail.example.com. >> >> Signed (and properly validated) RRSETs that contains these two records and a >> few more: >> >> mail.example.com. IN A 192.168.1.1 >> _426._tcp.mail.example.om. IN TLSA .... > > so anyone can spoof: > > example.net. IN MX 0 mail.example.com.
Yes, just like today. > pretending "mail.example.com." does not give you more security. What > would you do if you saw: > > example.net. IN MX 0 evil.nohats.ca > > with proper TLSA records for evil.nohats.ca? This is what we have today. I would deliver over the TLS secured connection. The only way to secure that is to DNSSEC sign mail.example.net. >> I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. >> that is a 100% properly setup DANE "thing". > > But nothing in that statement securely tells you anything about example.net. Correct. >> I think that behaviour is wrong, and am unsure whether it is a bug in >> postfix or whether it is a bug in the spec. > > That would be a bug in postfix? The spec states: > > All > "insecure" RRSets MUST be handled identically: in either case > unvalidated data for the query domain is all that is and can be > available, and authentication using the data is impossible. > > It does not state to not deliver email, it just states there is no > authentication possible, so deliver without dane authentication. Ok, I think what I have issues with is that I think "dane authentication" is not black or white. We have at least: 1. Signed and validated MX, signed and validated TLSA 2. Unsigned MX, signed and validated TLSA 3. Unsigned MX, no TLSA, unsigned A/AAAA Then we have all of the failed situations, which include: 4. Signed, but broken signatures, on MX, signed and validated TLSA 5. Signed, but broken signatures, on MX, signed but broken signatures on TLSA 6. Unsigned MX, signed but broken signatures on TLSA Etc So if you look at 1, 2 and 3, if I understand you correctly, [2] is not "DANE authenticated" even if the TLS connection has properly signed and validated TLSA record? This is a bit confusing to me. I.e. the terminology is confusing. To me, [2] has proper DANE validated TLS available for the SMTP connection. But I completely agree there is an MiM possible for the unsigned MX. Just like we have today. And why we want DNSSEC deployed. Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
