6:28 p.m.
On Thu, 14 Apr 2016, Linus Nordberg wrote:
| You could create/store a hash of the entire chain?
Possibly exclude the
| valid-from/expiry fields, so resigns of the same record time can be
| skipped for the log. Although it would be nice to see when certain
| records were resigned.
We do store the chain. The question is under what rules we should create
another log entry for a DS RR that already exist.
At least when the number of elements in the chain changes. Ideally when
any DNSKEY in the chain changes.
| Perhaps a simple cap of 12 per day would do? That allows us to catch some
| strange/unexpected resigns yet preventing spamming the log. Normal DS
| records should not have a validity of less then 2h.
What stops an attacker from generating 12 distinct chains and submit
them to the log, blocking any attacked client from submitting that day?
Nothing. But these attacks can only be mounted by your parent or higher
up in the chain, or you yourself. So I don't see the problem? We have no
600 different CA paths that can do things here.
| > - How stable is the chain? Should it be
included in duplicate checks,
| > canonicalisation assumed? No, RRSIG's expire and get replaced and are
| > not stable.
|
| The chain must be included because the parent could be skipping a
| delegation while keeping the same DS (for now), and we surely would want
| to log that event.
What does "skipping a delegation" mean?
Currently .ca hosts a DS for nohats.ca. The root could remove the NS/DS for
.ca and host the NS/DS for nohats.ca directly itself. Nothing would yet
change for nohats.ca, but now the root (instead of .ca) has the power
to change that DS directly. If the root zone publishes NS/DS records for
.ca, then the root cannot publish a DS for nohats.ca (we should test but
I hope all resolvers would call that a DNSSEC validation failure)
When you say "must be included", do you mean
that a log must accept the
same DS record twice if any bit in the chain is different?
Yes,
Paul