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…

paul at nohats.ca wrote Thu, 14 Apr 2016 11:08:14 -0400 (EDT): | On Thu, 14 Apr 2016, Linus Nordberg wrote: | | > | 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. | | I think we did discuss it and said it was needed :) OK. I probably just didn't understand. :) | While it is not very interesting for domains that were never signed, it | is of great interest to those that have had a DS in the past, as it | might be an attack by the parent to turn the child into insecure mode, | so they can then spoof any record of the child. Would you be able to describe how this should be done? Preferably in form of a patch to draft-zhang-trans-ct-dnssec-03. | > 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. | | It would require the two NSEC(3) records that prove this, but their | chain. Does not parse.

paul at nohats.ca wrote Thu, 14 Apr 2016 08:22:39 -0400 (EDT): | On Thu, 14 Apr 2016, Linus Nordberg wrote: | | > 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. | | 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. | 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? | > - 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? 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?

paul at nohats.ca wrote Thu, 14 Apr 2016 11:28:56 -0400 (EDT): | 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. This is useful. What about DS records in the chain? For this particular experiment where we're logging DS records in the root and a handful of TLD's it might not matter (or does it?) but let's say we'd like to use this implementation for logging DS records in paul.nohats.com? Disregarding DS records for establishing equalness between two chains for now, do you think that the following is a proper definition? - 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. | > | 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. Ah. Regardless of number of roots, this is just changing the number of accepted duplicates from 0 to 11. With a duplication check like the one outlined above, a log would still accept and expose | > | > - 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) I see, thanks. 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). | > 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.