On Thu, Nov 15, 2012 at 07:46:47AM -0800, Paul Hoffman wrote: > On Nov 14, 2012, at 10:14 AM, Shumon Huque <[email protected]> wrote: > > > 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 ... > > This is an excellent summary of the scenario. > > However, that's not exactly what Ben is asking about. CT-for-PKIX is about > "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is > about "did a server in the hierarchy above the leaf include a DS it should > not have". In the latter case, those rogue DS records might not be detectable > to the party with the leaf record. > > For example, assume the domain name example.newtld. The owner of example has > put DS record A in the newtld zone. If the owner of newtld goes rogue and > shows DS record B to a limited number of requests (such as to a particular > geographic region or set of network addresses), the party with the private > key associated with B can spoof example, and the owner of example would not > know unless he could see B. > > --Paul Hoffman
Good point. An auditable log of DS/SEP key chains would seem to be useful for this. -- Shumon Huque University of Pennsylvania. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
