Hi,
In a long response on the getdnsapi-users list [0] I reasoned about
validity and time. I'm sure this list could have good input on this.
[0] https://getdnsapi.net/pipermail/users/2016-February/000164.html
A short version is
- should a log limit submissions to those who are "fresh"?
- if so, what are resonable values for freshness?
- would this be useful for more than spam mitigation, i.e. good for
attribution as well?
Thanks,
Linus
Hi,
I'm ready to start testing some code. In order to save some time, I'm
asking the list for test data.
I suggest that we define "Inputs" for our newly invented "add-ds-rr"
HTTP entry-point (similar to RFC6962 section 4.1) like this:
chain: An array of base64-encoded RRsets in DNS wire format. The first
element is a single DS RR to be added to the log. The next element is
an RRSIG RR for the DS RR. After that follows all the RRsets necessary
to validate the DS RR up to a known root. The RR types allowed are
DNSKEY, RRSIG and DS.
Now please tell me where this will fail. :)
Or provide me with a chain like described above for a DS record of your
choice that's valid using the DNSSEC root as a known root.
Thanks,
Linus
Hi,
In an off-list conversation, it's been decided that logging of _removal_
of DS RRs would be useful. If those understanding why this should be
done could explain what attack(s) this will detect, that'd be great.
The next question is how this should be done in practice, in our current
experiment. IIRC we decided in Yokohama that Paul would hack up an
unbound to submit DS records it stumbled over, together with a chain of
keys and signatures up to a trust anchor that the log had configured.
I'm going to show my ignorance and ask how this would be detected and
expressed while pointing out that "duh, NSEC*" is _not_ enough for me to
understand. :) I do accept terse descriptions and pointers to relevant
litterature though!
Thanks,
Linus
Hello everyone.
I recall the rather harsh discussions in Yokohoma. And now during the
off-the-list discussions I had an impression that we aren't on the same
page as for the goals of this effort.
Can we clearly formulate what are the security goals of DNSSEC transparency?
My concern is that not all Certificate Transparency goals will be
applicable to DNSSEC. And I want to be sure that the result of our
effort will be useful.
Best regards,
Jan
Hi,
We want the log to store not only DS RRs but also all keys (DNSKEY) and
signatures (RRSIG) needed to verify the issuer of the DS.
We want to require that submissions include this chain so that the log
doesn't have to chase them.
What's a good wire format for such a chain?
