4:45 p.m.
Willem Toorop <willem at nlnetlabs.nl> wrote
Thu, 14 Apr 2016 12:22:08 +0200:
| Op 14-04-16 om 11:20 schreef Linus Nordberg:
| > Hi,
| >
| > The draft is not precise on the question of what comprises an entry with
| > regards to duplicates. Here are my thoughts about this today:
| >
| > - Duplicate checks are important to get right to avoid the log being
| > spammed to death.
| >
| > - Should we perform duplicate checks on the key only, i.e. DS RDATA?
| > That's what we're interested in detecting misisuance of after
| > all. Well, owner name has to be included too. Type and class are
| > fixed, leaving us with TTL. Since canonicalisation of the DS record
| > sets its TTL to the Original TTL Field of the covering RRSIG, TTL
| > might be stable enough to be included in duplicate checks.
| >
| > - 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.
|
| Also, there might be multiple RRSIGs that provide multiple different
| ways to validate the DS.
|
| If the DNSKEY RRset (+ RRSIGs) associated with a DS RRset would also be
| stored with the DS, then it should be possible to construct a chain of
| trust at a specific time from the log.
That is what is being done today. We do what
draft-zhang-trans-ct-dnssec-03 says in section 4.1 and store a
DSRR_Chain_Entry.
struct {
DNSSECRR DSRR;
DNSSECRR DNSSEC_key_chain<0..2^24-1>
} DSRR_Chain_Entry;
[...]
"DSRR" is the DS RR submitted for auditing.
"DNSSEC_key_chain" is a chain of additional DNSSEC RRs required to
verify the DS RR.A typical authentication chain is as follow: Trusted
DNSSKEY ->[DS->(DNSKEY)*->DNSKEY]*-> Submitted DS RR, where "*"
denotes zero or more sub-chains. (DNSKEY)* indicates that DNSSEC
permits additional layers of DNSKEY RRs including the keys for
signing other keys within a zone. Each DNSKEY/DS RR in the chain is
authenticated by a RRSIG RR. In practice, a RRSIG RR is normally
used to sign a DS/DNSKEY RRset. Therefore, not only the DS/DNSKEY RR
on the authentication chain but also other records in the RRset
SHOULD be provided to the log the verification purpose. Otherwise,
the log may have to consult DNS again in order to verify the
The question is what exactly should be considered an entry with respect
to duplicates in the log. The more data we include in the duplicate
check, the more data the log will have to carry. Forever. So there is a
real argument for _minimising_ the data in order to save the logs from
growing too fast.
There's also a real argument for not refusing to store submitted
information (by sending back an old SCT for an entry that "matches" the
submitted one) in the case where the information contains something we
don't already have which at the same time also is interesting for
detecting misisuance.
| Is the absence of a DS also stored in the log? I.e. the NSEC(3) proof?
No. That is not in the draft and was not something we discussed at the
DNSSEC Trans meeting in Yokohama as far as I can recall.
Interest in this has been expressed on this list before [1] but no
concrete suggestions on how this should be done have been presented so
far.
[1] https://lists.sunet.se/pipermail/dnssec-transparency/2016-February/000004.h…