On Tue, May 13, 2014 at 9:58 AM, Ben Laurie <[email protected]> wrote: > On 13 May 2014 15:53, Daniel Kahn Gillmor <[email protected]> wrote: >> So if Alice registers example.co.uk, she wants to do misissuance review >> for that zone. But in a DNSSEC context, she needs to do misissuance >> review of the parent zones as well. That is, she wants to ensure that >> .uk is not publishing spoofed records about the .co.uk nameservers and >> zone signing keys (how does she know if a change in DNSSEC records at >> this layer is a legitimate change?). > > I don't get why Alice would want to do this - all Alice cares is that > example.co.uk is correctly issued, right?
To detect MITM attacks by uk. on her peers. Of course, given caching... it's going to be very difficult for uk. to mount a targeted MITM attack on Alice's peers. That's not the case with the PKI because there's no lookup process there, so no caching. Still, it seems reasonable for Alice to check uk.'s log. Besides, the cost of doing so is marginal: in general the closer to the root in DNSSEC the lower the log volume (what do we call this?) will be. >> How does she know what logs to look in for this misissuance review? Is >> there a way she can do this review efficiently? I think these questions >> are relevant for regular CT as well, but a DNSSEC-focused CT adds the >> wrinkle of delegated zones. (maybe this isn't actually worse than X.509 >> PKI with its fully-delegated intermediate CAs though?) > > My naive first crack at this question was: each parent designates where its > children are logged (which may be the same log as the parent, of course, but > allows the parent to delegate for big/spammy users). Right, . won't want to share a log with com., no doubt. But that's not an answer to Daniel's question, which is about whether Alice's auditing job is easier or harder in the DNSSEC case compared to the PKI case. IMO it's easier; I explained my answer separately. Nico -- _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
