You mention that you only bother if the MX RRset was secure. In the Gmail case, we've got a lot of customers using "google apps for your domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM
Let's say hypothetically ianfette.com has an MX record for ASPMX.L.GOOGLE.COM but the administrator of ianfette.com can't be bothered to set up DNSSEC. That implies that even if google.com had deployed DNSSEC and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored? On Thu, Sep 5, 2013 at 2:56 PM, Viktor Dukhovni <[email protected]>wrote: > On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (????????) wrote: > > > My reading of DANE says that if a TLSA record is not verified by DNSSEC, > > you should basically ignore it. > > Correct. RFC 6698 specifies that TLSA RRs are only valid in "secure" > zones. > > > On SMTP, today you're going to connect on port 25, and you're going > > to either not see STARTTLS in which case you presumably will send > > mail unencrypted, or you will see STARTTLS and as we discussed > > earlier in this thread, probably just take whatever certificate > > you get and hope for the best. > > If all you want is protection against passive eavesdropping, > opportunistic TLS (without DANE) is sufficient. The attacker cannot > suppress STARTTLS (after all the attacker is *passive* by hypothesis). > > If you have an active attack (man in the middle), where STARTTLS > can be supress, it is trivial to also supress insecure DNS responses. > In fact, for many adversaries, it is likely easier to forge DNS > replies than to interpose themselves into the middle of a network > connection. > > So I don't think there's much point in processing insecure TLSA > responses. Postfix typically does not even bother with the query. > TLSA RRs are queried for each MX host only when the MX RRset was > secure. When the MX host names can't be trusted, no TLSA query is > issued. So bottom-line, no support for insecure TLSA RRs in Postfix > at this time. > > Postfix also has a "dane-only" security mode which can be enabled > for selected destinations. This requires successful DANE authentication > of the destination's SMTP servers, the code for that use-case > definitely must not honour insecure TLSA RRs, and it would complicate > the implementation to handle DNS lookups for "opportunistic" and > "mandatory" DANE differently. > > In terms of DNSSEC adoption, aside from paypal.com, which is in a > very different market segment, comcast.net and comcast.com have > been secured with DNSSEC for quite some time now. They have not > yet published TLSA RRs for their MX hosts, if anyone knows the > email administrators at comcast well enough to nudge them in > the right direction, please do so... > > -- > Viktor. > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
