editorial via kevin fleming

[moonshiner]

1. Introduction - "As such differ the confidence into the Trust to designate which DNSKEY RR is legitimate." I don't understand what this sentence is supposed to mean.

2. Introduction - "The chain of trust is obtained by recursively validating the DNSKEY RRs." This sentence appears before the paragraphs which describe the recursive DNSKEY validation process and before any indication of the fact that there are even multiple DNSKEY RRs involved (in most cases).

3. Introduction - "Keys for a name will "vouch for" keys at a name delegated via the signing of a DS resource record set." The signing of the DS RRset isn't the delegation process, the delegation process is the addition of NS records for the domain being delegated. Also "Keys for a name" is repeated in this sentence and I suspect the two uses are referring to different things.

4. Introduction - "Once accurately validated the RRset is assumed to be accurately validated and trusted during the time indicated by its TTL." This is repetitive, and it's not clear to me that 'accurately' is providing any value here, because the RRset is either validated or is not validated; it cannot be 'inaccurately' validated. I see that in section 3 there is a definition of 'accurate validation' but I don't think this is as helpful as intended, as a validator can return a 'false negative' response for reasons which are completely outside of its control (and some are noted in the document) but this does not make that response 'inaccurate'.

5. Introduction - "The responsibilities of a DRO are limited to the management of TAs as well as providing the necessary infrastructure to perform the signature validation, e.g. appropriated libraries and time." Disregarding the misuse of 'appropriated' I believe this sentence is incorrect. The responsibilities of a DRO include all activities required to operate the recursive resolution service they are offering to their users, not just the aspects related to DNSSEC validation.

6. Section 3 - "Trust Anchor Data Store: a module (of code) implementing functions related to the trust anchors used by the validator. This is essentially a database allowing access, monitoring of, and changes to trust anchors." I don't think it is useful to refer to this as "a module (of code)", as it may not be a distinct module in the DRO's chosen implementation, and it might not even be code! It is conceivable that a DRO may choose to use something analogous to an HSM for storing Trust Anchors.

7. Section 4 - "Time Source: The wall clock time provides the DNSSEC Validation Engine the current time. Time is one input used to validate the RRSIG Signature and Inception Fields to provide some protection against replay attacks." Unless the reader of this document keeps their 'wall clocks' in UTC, the timestamps used in DNSSEC are not wall clock time.

8. Sections 3 & 4 - Section 3 defines "Trust Anchor Data Store", and Section 4 redefines the same concept as "Trust Anchor Manager", without referring to the previously-defined Trust Anchor Data Store. In fact "Trust Anchor Data Store" is never used in the document beyond its definition.

[kpfleming]

Just for clarity, this was just the first round of issues that I found when reviewing the document. I'm happy to continue with the review and raising more issues, if that's what the authors would prefer.

[moonshiner]

Kevin, you willing to do a deeper read?

[kpfleming]

Yes, I can do that later this week.

[moonshiner]

That works!