8:32 p.m.
On Fri, 15 Apr 2016, Linus Nordberg wrote:
| At least when the number of elements in the chain
changes. Ideally when
| any DNSKEY in the chain changes.
This is useful. What about DS records in the chain?
Sorry, what I meant to say was "when any key in the chain changes". you
can log that by either logging DNSKEY and/or DS.
Disregarding DS records for establishing equalness
between two chains
for now, do you think that the following is a proper definition?
We do need the DS records because those are the signed delegations by
the parent. I guess we need the DNSKEY records so we can independantly
validate the chain.
- Two submissons, A and B, are considered equal iff
all of the
following is true
- the canonicalised DS RR in A and B are bitwise equal
- the number of DNSKEY RR's in A and B are equal
- all DNSKEY RR's in A and B are bitwise equal
- Accept up to 12 duplicates per day.
I'd like to point out that the contents of the chain is _not_ covered by
any of the log signatures (in SCT's or STH's). This because we're
adapting RFC6962, as per the draft. One effect of this is that a log can
change the contents of any chain without risk being held responsible for
it, at least not cryptographically.
We should think about that in the future. Please treat the draft only as
a first prototype idea, and not as the required solution.
Wouldn't it be sufficient if we detected when the
DS was actually
changed? The price of detecting this kind of preparation of an attack
might be non-zero. If it can be done at all (see comment about chain not
being signed above).
We can punt it for now, but I think it is useful to add once we decide
how to log the entire chain.
| > 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,
This ("any bit") contradicts the idea presented above where only the
number of and the contents of the DNSKEY RR's were suggested to affect
the process of determining if two chains are considered equal or
not. Unless I misunderstood you above.
I think we would also want to know when the DS hash algorithm changes,
even if the same key is used. For example, let's say someone finds a
SHA1 attack, and they degrade the DS hash algo from SHA256 to SHA1, so
they can then perform a targetted attack. The change of algorithm would
signal that attack. It would also be interesting to find one domain
received an algo X and other domains received an algo Y hash algorihtm.
Again, for a first prototype we can ignore these for now.
Paul