Zitat von Patrik Fältström <[email protected]>:
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 EtcSo 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.
You are https biased i guess. With an unsigned MX your secure chain is broken because the target you try to reach by an E-Mail address is directed to a target by an "unsecure" link. If the unsecure resolved target is then secured doesn't matter because you might be already on the wrong track.
Security is only as strong as the weakest point in the chain. Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
