On Mon, May 12, 2014 at 12:22 PM, Joseph Bonneau <[email protected]> wrote: > I'm wondering what the exact threat model is here. Imagine a malicious > domain operator wants to sign some DNSSEC records for use in an attack. They > include hashed of them in their log, then claim to "lose" the original > records, or issue the equivalent of SCTs and then never include them within > the MMD. Who is checking up on them for this? Does the superdomain that
Clients (lazily perhaps). The public. Domain owners. Registrars. Remember, com. and . cannot merely MITM foo.bar.com. com. would have to MITM bar.com. as well. And . would have to MITM com. too. These would be noticeable. > signs this domain's record has to be doing full auditing of their DNSSEC-CT > log? Does this still work then as anti-DOS if the superdomain has to do all > of this auditing anyways (I suppose it could be made random, but then the > domain can try to hide malicious entries with lots and lots of spam ones). "Loss" of log entries gets detected. Detection of MITM attacks by . and TLDs would result in bad PR, and the news would spread quickly, therefore they [mostly] wouldn't do it. That's the point of CT. I don't understand you question about anti-DOS. > Furthermore, is this requirement recursive? What if a malicious domain > evil.com agrees with a subdomain really.evil.com to not audit their > DNSSEC-CT log properly, so malicious records can be signed for > really.evil.com, not audited by evil.com, but if com (who we assume is > honest) only audits evil.com's log they'll think it's in valid order. Is > there a way to prevent the root from having to audit every log everywhere? Domains would get to opt out for privacy reasons. If evil.com opts out, oh well. This isn't about auditing every zone. > Also, the penalty for failing some audit check is losing control of your > domain? [...] Eh?! Who said that?? Nobody proposed that; nobody would. Failure to include signatures in the log -> detection -> bad for public relations -> incentive for CAs/registrars not to MITM. Nico -- _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
