Re: [Trans] DANE transparency

[Ben Laurie <[e-mail]>]

On 25 July 2014 11:59, Richard Barnes <[e-mail]> 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.