On Wed, Nov 14, 2012 at 05:56:24PM +0000, Ben Laurie wrote: > On 14 November 2012 17:29, Shumon Huque <[email protected]> wrote: > > On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: > >> On 14 November 2012 17:02, Tony Finch <[email protected]> wrote: > >> > Warren Kumari <[email protected]> wrote: > >> >> > >> >> If I run example.com and someone managed to generate / publish a TLSA > >> >> record for that I'd sure like to know about it. > >> > > >> > Right. But in PKIX a mis-issued certificate has nothing to do with your > >> > own infrastructure, whereas with DANE it implies that your infrastructure > >> > (or the infrastructure of your DNS service providers) has been > >> > compromised. > >> > >> Isn't the infrastructure of your DNS service providers nothing to do > >> with your own infrastructure? Not to mention your TLD's > >> infrastructure, and that of all of their registrars (and, presumably, > >> DNS service providers)? > > > > One critical difference is that with DANE, I can query the DNSSEC > > delegation chain myself and detect whether my TLD has installed a > > bogus DS record and take action. I cannot today detect a bogus > > X.509 cert by myself. I think this makes a CT like scheme less necessary > > for DANE. > > You can't detect a bogus X.509 cert because you can't connect to the > server serving it, presumably. What magic allows you to perform this > trick for DNS but not HTTPS?
For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC authentication chain, not the existence of a fraudulently issued certificate on some attacker's server. If the DNSSEC chain is intact, then presumably DANE aware clients will properly authenticate the TLSA record before accepting the server certificate. I admit that's a mighty presumption today, but we'll see ... -- Shumon Huque University of Pennsylvania. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
