On 8/3/2025 15:12, Paul Wouters wrote:
On Aug 3, 2025, at 12:38, Michael StJohns <[email protected]> wrote:
Hi - apologies, I wasn't paying attention as I thought this would
have been a simple and clean document.
Mukund's note made me take a quick look a this. I think the document
is incomplete or ambiguous.
Please add a reference to RFC 4035.
That is a partial reference to DNSSEC. It should be RFC 9364 (or BCP 237)
Nope - that document doesn't contain the text that needs to be
referenced below. (E.g. 4035 section 4.3). 4034 is already in the
references, but doesn't define the set of terms we use when talking
about secure/insecure/bogus/unknown (indeterminate)
Please add a sentence or two that says something like "Insecure, with
respect to DNSSEC, has the meaning given to it per [RFC4035],
section 4.3." if that's what you mean by "insecure". I'm not sure if
you meant that or Bogus.
Bogus is never the same as insecure. Bogus represses the Answer
Section content, while insecure does not.
You know that, and I know that, but this document uses "insecure"
without explaining what that means in DNSSEC terms. Given the other
Paul's comments, if you've got an AUTH48 period (and given that the
current doc status is "Version changed, review needed", you may want to
add just this. The rest of this was more seeking a clearer way of
saying things, but is probably technically correct with this clarification.
Should a SHA1 signature over a DS record be treated differently than
a signature over other records? E.g. Is a SHA1 signature in a signed
zone over a DS record bogus, or can it be treated as if it weren't
present? If the latter, is the subordinate zone securely insecure,
or bogus?
It should either be validated or treated as not existing (aka
insecure). It MUST NOT cause bogus.
Yup - document doesn't say that in so many words.
The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms
MUST NOT be used when creating DS records. \
This is fine. But instead perhaps.:
The RSASHA1, and RSASHA-NSEC3-SHA1 algorithms MUST NOT be used
when creating DS records; authoritative servers MUST NOT serve DS
RRSets containing these records;
You don’t want to define a new code path where an auth server is going
to filter out part of the zone file it is given.
This is the thing that I keep saying - humans are not protocol elements
and enforcing MUST NOT be used... is really pointing at the data
creation process. Code ought to do the enforcement, not assume the
human creating the zone information is doing it correctly. All I mean
by the above, is that there ought to be some automated enforcement point
PRIOR to the records making it to the server, not just trusting people
to do the right thing.
Also records aren't secure or insecure, RRSets and validations
results are secure or insecure. A DS RRSet containing both SHA1
and non SHA1 delegations signed by a non-SHA1 algorithm is secure
(assuming a chain of trust) for example.
Yes, agreed.
Paul
I'll pay more attention... thanks - Mike
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
