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. | Are you only converting individual rr_dict's or complete replies as | well? For complete replies it could also be interesting (for other use | cases) to explicitly ask for name compression. My validation program reads a set of RR's in wire format where the first RR is a DS RR, the next one is an RRSIG RR covering the previous DS RR and the rest are "support records", including RRSIG's.

Paul Wouters <paul at nohats.ca> wrote Sun, 3 Apr 2016 14:49:26 -0300: | > | > My validation program reads a set of RR's in wire format where the first | > RR is a DS RR, the next one is an RRSIG RR covering the previous DS RR | > and the rest are "support records", including RRSIG's. | | Note you need to be able to accept any order of RRdata if you get the | order that came in on the wire (because at least powerdns randomized | the rrset) I'd like to require that the first record is the DS to be added to the log. This in order to know _which_ DS in the rrset to add. Unless I'm to pick the one with the "longest" owner name, but that seems icky. An alternative would be to separate the DS (and its RRSIG) from the chain by adding another input beside 'chain' (as described in draft-zhang-trans-ct-dnssec-03 section 6.1). Regarding what powerdns does or does not, I'm expecting someone to implement a client for this log that formats the data according to the draft, or something else that we decide upon.

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!

Willem Toorop <willem at nlnetlabs.nl> wrote Wed, 6 Apr 2016 15:21:25 -0300: | > | 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. Interesting. Glad to see a followup on agl's thing that you mentioned in Yokohama. Seems useful. | 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. OK. | > 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. I see. Good info. Since I require, even if the dnssec trans draft does not, that the client includes the RRSIG for the DS in the submission (avoiding the log to add pieces of information from its own view of the DNS tree) I guess it doesn't seem crazy to "rewrite" the DS like this before checking for a duplicate. (If there's already an entry in the log matching the submitted record, we don't want to store the record again.) Any thoughts on pros and cons?