It seems like we're letting the perfect be the enemy of the good. At the end of the day, what I would like to signal is that servers should expect to talk to Google's mail servers using TLS. I would also like to know what servers expect Google to talk to them using TLS. There are a few ways I can think of accomplishing this, one being DANE, another being something similar to HSTS (RFC6797), and I'm sure we can come up with a fair number of other mechanisms as well. Each of them has their drawbacks. I would love it if I could deploy DNSSEC on google.com tomorrow, but much as I may want that it's not going to happen overnight. HSTS-style approaches don't let me know a-priori what to expect from a new domain, but given our scale that's not actually such a huge problem. As such, I'm trying to understand what incremental steps I actually _can_ take. And so here we are choosing between options that offer some additional benefit but don't solve all problems, as is often the case in the messiness of the real world, and I'm hoping that perfect need not be the enemy of the good.
On Thu, Sep 5, 2013 at 3:24 PM, Viktor Dukhovni <[email protected]>wrote: > On Thu, Sep 05, 2013 at 03:12:05PM -0700, Ian Fette (????????) wrote: > > > You mention that you only bother if the MX RRset was secure. > > Correct. > > > 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 > > Yes, I've seen such domains. > > > 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? > > Correct. A chain is only as strong as its weakest link. When the > original MX RRset is insecure, the base domain for the TLSA RR is > subject to compromise. There is then no point in making TLSA > lookups even if the MX host domain is DNSSEC validated. > > A domain only benefits from DANE, when *it* adopts DNSSEC. If it > out-source MX service, the hosting domain also needs adopt DNSSEC. > > ; client record in signed zone > ; > example.com. IN MX 0 mx.example.net. > > ; provider record in signed zone. > ; > mx.example.net. IN A 192.0.2.1 > _25._tcp.mx.example.net. IN TLSA 3 1 1 ... > > If either zone is insecure, TLSA records are ignored. > > I think this should not dissuade you from implementing DANE, there > are plenty of users to protect in gmail.com itself. If client > domains have more reason to implement DNSSEC, that's for the better. > > -- > 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
