[Trans] DANE transparency

[Richard Barnes <[e-mail]>]

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