Hi, I have *not* followed this wg in detail, although I have talked with various people about how important it is to get DANE deployed. I am also strongly advocating use and deployment of DANE as I personally think the current CA/X.509 PKI structure is broken beyond ability to fix it.
I read a text by Jan Žorž: <http://www.internetsociety.org/deploy360/blog/2015/08/even-more-danednssectls-email-testing-from-go6lab/> That made me a bit confused as I interpreted the text as if mail was not delivered in one case where I think email should be delivered. I have in Facebook had a long discussion with Jan, and the more I think about it, the more I think I am right ;-) I have re-read the very very very long I-D (draft-ietf-dane-smtp-with-dane) that is now in RFC-Ed Queue and I think unfortunately the huge number of words, lack of flow chart (decision making tree) and lack of real world examples makes it hard to know what the document says. At least I can not say directly whether the draft really say anything at all about this example I am to bring up. But all of this might imply I am wrong of course. If nothing else because I have not followed the discussions. Ok, to the example: Delivery of email consists of two steps: 1. Resolution of MX record. And if no MX exists, fallback to A/AAAA In my example, we DO have an MX record. To me this is 100% normal DNSSEC. Question on whether the target of the MX is to be trusted is up to the policy we use for DNSSEC. Also, in my example the RRSet the MX is in is _unsigned_: example.com. IN MX 0 mail.example.net. 2. Delivery of the mail over TLS to mail.example.net. This is where DANE comes in. For the cert to be trusted, there must be a TLSA record for _426._tcp.mail.example.net, and it must be DNSSEC signed, signatures validated etc etc. This step 100% validates and is correct according to traditional DANE. Ok, how then to put these pieces together? I think these two steps are independent of each other. And DANE should be used, the cert be accepted, if step 2 is properly validated, TLSA record signed and validated etc. Regardless of whether the MX was signed. That said, the sender CAN have a policy that say that "For me to base my trust on DNS (and not X.509 CA hierarchy), MX must be signed with DNSSEC and properly validated." But, default must be to allow unsigned MX together with a properly setup with by DANE validated cert that is used in TLS. If not, we will get absolutely zero deployment of DANE with SMTP as we will never get 100% DNSSEC deployment. And if DANE is so good, which I think, and I hope all of us think, why should not a TLS connection that is properly secured with DANE not be accepted for SMTP? No, I do not think the MiM attack vector is _worse_ with unsigned MX but properly validated TLSA than what we use today without TLS and unsigned MX. And no, I do not think todays X.509 CA use is very good at all. As some of you know. Best, Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
