I didn't get my thoughts put together in time to get to the mic in the meeting today, but here's roughly what I was going to say:
tl;dr: Spam on CT logs is the only major problem to solve here, and protocol is probably not the way to solve it. Doing transparency for the whole of DNSSEC is an unsolvable problem. It's massive, like Wes pointed out, and littered with tautological pitfalls. I could imagine some form of "DNSSEC pinning" allowing subordinates to impose hysteresis on frequently-accessed domains, but going further than that quickly approaches the madness that Stéphane noted. Instead of focusing on the internals of DNSSEC, we should focus on the things that actually impact protocol, i.e., the TLSA records at the leaf. Normal CT is totally sufficient for these -- certs/pubkeys asserted in TLSA are still certs/pubkeys. If we need to change the syntax to capture things slightly differently, we should do that, but it seems straightforward. The only reason that chains are needed in CT is to defend against spam. With DANE, the potential spammer is the authority, so he can make as many spam domains as he wants. So the "DNSSEC chain" is useless for spam mitigation. It's all so possible that DANE-asserted certs will change more often, so again, we might want to tweak what's logged (e.g., to log the public key). Fairly minor change. We're left with the question of how to prevent spam. I'm not sure there's a protocol mechanism here. It seems like you could have a local policy at the log to, say, limit the rate of updates that are accepted. So I think we should: 1. Forget about solving DNSSEC transparency generally 2. Focus on getting CT ready for DANE 3. Identify any tweaks that are necessary to support DANE-asserted certs 4. Maybe write some guidelines for anti-spam --Richard
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
