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

[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.

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.



| 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!