Subject: [Trans] DANE transparency

From: Richard Barnes <[email-masked]>
Date: Fri, 25 Jul 2014 11:59:53 -0400

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

---

From: Ben Laurie <[email-masked]>
Date: Mon, 28 Jul 2014 15:15:26 -0400

On 25 July 2014 11:59, Richard Barnes <[email-masked]> wrote:
> tl;dr: Spam on CT logs is the only major problem to solve here, and protocol
> is probably not the way to solve it.
>
> 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:

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Jul 2014 15:42:09 -0400

> general DNSSEC transparency project.

+1

Unless DANE is bjorked, it should be easier to apply DANE to the
DNSSEC system and then DANE rather than just DANE/TLS.

The only advantage to doing it piecemeal is that you have more wiggle
room. Which is very useful when dealing with an infrastructure like
SMTP where the biggest problem you always face is the deployed legacy
base.

Using wiggle room when you shouldn't need it is going to result in a
spec that is stovepiped to one application and will be very hard to
port to anything else.

On top of which, DANE's achilles heel is the problem of deployment.
Getting all the folk who need to move in one direction is really hard.
We will have a functioning TRANS system operational long before
DNSSEC. So using TRANS as leverage to deploy DNSSEC makes a lot more
sense than waiting around.