On 25 July 2014 11:59, Richard Barnes <[email protected]> wrote: > 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
Two points: 1. In the limit, is there really a noticable difference between doing transparency for DANE and doing transparency for all of DNSSEC? 2. DNSSEC surely exists for reasons other than to secure TLSA records. I therefore don't buy that there's no point to making the rest of DNSSEC transparent. Which is not to say that a DANE-specific transparency project isn't worth pursuing, but I don't think doing so removes the value of a general DNSSEC transparency project. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
