[getdns-users] [DNSSEC-Transparency] Example using the "dnssec_return_validation_chain" extension

[Willem Toorop]

Op 06-04-16 om 12:51 schreef Linus Nordberg:
> Willem Toorop <willem at nlnetlabs.nl> wrote
> Wed, 6 Apr 2016 11:35:13 -0300:
> 
> | Op 03-04-16 om 13:59 schreef Linus Nordberg:
> | > Willem Toorop <willem at nlnetlabs.nl> wrote
> | > Sun, 3 Apr 2016 12:46:24 -0300:
> | > 
> | > | Op 03-04-16 om 09:10 schreef Linus Nordberg:
> | > | > 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.
> | > | 
> | > | Ok... well, then we need to do something about it :)
> | > | So, the conversion to wireformat functions already get rid of
> | > | compression if you remove the /rdata/rdata_raw fields from the rr_dicts.
> | > |  I suppose it could be an extra parameter in that conversion function to
> | > | write out canonicalized form.  Or a different function names...  for
> | > | example:
> | > | 
> | > | getdns_return_t
> | > | getdns_rr_dict2canonical_wire(
> | > |     const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
> | > | 
> | > | getdns_return_t
> | > | getdns_rr_dict2canonical_wire_buf(
> | > | 	const getdns_dict *rr_dict, uint8_t *wire, size_t *wire_sz);
> | > | 
> | > | getdns_return_t
> | > | getdns_rr_dict2canonical_wire_scan(
> | > | 	const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
> | > | 
> | > | What do you think?
> | > 
> | > That'd be very useful for my purposes.
> | 
> | Yes, I've been chewing on this a little bit, and considering that
> | canonical order also seems important, perhaps we can come up with some
> | more generic functions.
> 
> I've been looking a bit closer at draft-zhang-trans-ct-dnssec-03 and
> think that I only need the submitted DS record to be canonicalised. So
> no ordering is necessary and only section 6.2 of RFC4034 needs to be
> considered in my case.
> 
> If you don't think there's a good reason for adding the feature of
> returning canonicalised records in getdns, I could probably handle this
> myself.

Linus,

After a meeting a few minutes ago about
draft-shore-tls-dnssec-chain-extension-02, I realize I need to have
those functions for our draft anyway.  So they will be added.

I will also consider returning the validation chain already
canonicalized and sorted as a future improvement.  Currently this is not
the optimal path; the chain is extracted from the actual replies and not
the verification buffers.  Plus, you need the separate functions to
canonicalize the answer anyway.  But it might be a good future optimization.

> 
> If so, can this list explain if point 5 in RFC4034 section 6.2 is
> applicable to this case, a DS record? I don't really understand it.
> 
>    5.  the RR's TTL is set to its original value as it appears in the
>        originating authoritative zone or the Original TTL field of the
>        covering RRSIG RR.

When you lookup the DS at a recursive resolver, the TTL will be the time
it has left in the recursive's cache and not the TTL that the DS had at
the authoritative server.  That TTL is in the "Original TTL" rdata field
of the RRSIG associated with the DS.  It would make sense for DNSSEC
transparency log to store the "Original TTL" with the DS yes.

-- Willem

> 
> 
> 
> | For example one to canonicalize a single rr_dict:
> | 
> | getdns_return_t
> | getdns_rr_dict_canonicalize(
> |     const getdns_list *rr_dict, getdns_list **canonicalized_rr_dict);
> 
> Should getdns_list be getdns_dict here? Or will the function perform
> canonicalisation of all dicts in the list?
> 
> 
> | and one to sort:
> | 
> | getdns_return_t
> | getdns_rr_dicts_sort(const getdns_list *unsorted, getdns_list **sorted);
> | 
> | where the sorting function makes sure the signature rr_dicts are right
> | behind the rrsets they sign.
> | 
> | What do you think?
> 
> I think this would be useful, not the least for analytic and test
> tools. If it's not too much work, I think it'd be a good idea!
>