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.
- If chains are not included in duplicate checks, is there any point in
storing a canonicalised version of the chain? Are there any downsides?
I note that if canonicalisation would mean sorting the RR's, we'll end
up storing the RR's in a different order than what the client use when
submitting. That might be a bit unintuitive, for implementors of
monitors at least. But perhaps canonicalisation shouldn't sort like
that? Sorting _within_ an RR set is different from sorting all the
RR's in the chain, I suppose.
Thoughts?
Hi,
The code in branch 'dnssec2' of my catlfish repository [0] can be used
for starting a log which accepts DS records with a chain ending in one
of the configured trust anchors. See README.dnssec.md [1] for a
specification, i.e. where we don't follow
draft-zhang-trans-ct-dnssec-03.
[0] git clone https://git.nordu.net/user/linus/catlfish.git
[1] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_plain;f=README-dnss…
A major thing that does not work yet is 'make tests'. All the
integration tests are written in Python. We need to do things like read
an RRset in wire format and chop it up in RR's. Is it easiest to just
write the code for doing that, rather than figuring out how to make
dnspython or dnslib do it?
As soon as 'make tests' is happy, I'm setting up a single-frontend,
single-mergenode log on a NORDUnet server.
Then on to a submitting client. What do people envision here? A
standalone program "crawling" the zones at hand and submitting
every DS it sees? Something running as part of a resolver, submitting DS
records passing by? Something else?
Willem Toorop <willem at nlnetlabs.nl> wrote
Sun, 3 Apr 2016 08:45:45 -0300:
| > Next question is if I can somehow access the canonicalised data that the
| > validation is based on? From skimming the code, it seems to me that
| > canonicalisation is performed but I haven't figured out if it's safe to
| > assume that I could simply use the data in getdns_list's that I passed
| > to getdns_validate_dnssec2() once it returns.
|
| No, the verification buffers are temporarily used for the verification
| process only. But why do you need the canonicalized form?
(Cross posting to dnssec-transparency@ where this discussion is more on
topic.)
A DNSSEC Transparency log server should store RR's in canonicalised form
in order to be able to return an old SCT when a submitted record already
exists in the log. Without this it'd be even easier to spam a log to
death.
At least that's my understanding of why this is important. Another less
important reason would be to make it easier for auditors and monitors to
verify log behaviour and content.
Thinking some more about it, duplicate checks should probably be
performed on the submitted DS record (and possibly its accompanying
RRSIG) only. I'm still pretty sure it should be canonicalised.
Hi dkg,
Sorry to put you on the spot but I haven't been able to establish
contact with any of the other authors of draft-zhang-trans-ct-dnssec
yet.
I have two questions / suggestions:
- Remove issuer_key_hash
The draft refers to 6962-bis but "issuer_key_hash" was removed in -05.
The issuer_key_hash is useful for pre-certs but not for DNSSEC
AFAICT. Bu maybe I'm missing something?
- Define BinaryDigest in SignedCertificateTimestamp
The signed_entry struct in SignedCertificateTimestamp has two types of
type BinaryDigest. Should the type be DSRR? Why two?
Thanks!
Hi,
The 'dnssec' branch in my public catlfish repo at git.nordu.net [0] now
has working unit tests for validating a DS record, given all support
records (including RRSIG's for all the RR's). Let me know if you need
any help setting things up. We need more tests.
Next step is to add system tests, and getting a full system up and
running.
[0] git clone https://git.nordu.net/user/linus/catlfish.git
Hi Melinda,
Looks like https://dudle.inf.tu-dresden.de/privacy/dnssec-trans-ietf95/
didn't attract much attention.
Wanna postpone to week after IETF or go for Wed or Thu? Meeting tonight
has become a bit rough for me. Sorry about that.
Also, help with a client would be much appreciated!
Hi!
Would anybody be interested in a 1h chat meeting regarding DNSSEC
Transparency? I've created a poll for finding a time during this weeks
IETF meeting in Buenos Aires. There are two suggestions per day, the
first being in the lunch break and the second being after the last
session.
https://dudle.inf.tu-dresden.de/privacy/dnssec-trans-ietf95/
I know that the IETF week is hectic for most people who attend but it's
also a good time for getting things nailed down, so I thought I'd try.
A couple of things I'd like to hash out during such a meeting are
- Is the suggested format for a submitted DS RR with chain thought
through or is it more of a straight translation from CT?
- Who's willing to write a client useful for submission?
- Who's interested in running a frontend system? We're getting closer to
having some code to run and I'm curious if you're going to prefer some
specific OS or distro, or if you perhaps fancy Docker more.
- A rough road map would be useful.
Thanks,
Linus
