[DNSOP] Re: Secdir early review of draft-ietf-dnsop-compact-denial-of-existence-04

[Michael Sinatra <[e-mail]>]

I have also added a nit (as an Issue) to the github repo for this doc, 
as I'd like the authors consider explicitly stating that the inability 
for resolvers to synthesize NXDOMAIN responses for zones using this CDoE 
mechanism can make certain DOS attacks (e.g. Water Torture) more 
effective than with plain NSEC.

https://github.com/shuque/id-dnssec-compact-lies/issues/6

I realize that a close read of Section 5 of the draft makes it clear 
that RFC 8198 aggressive ncaching won't work, but it might be useful to 
also call that out as a security consideration (i.e. the effectiveness 
of Water Torture relies on the *lack* of negative caching).  Happy to 
discuss further if the authors desire.

michael

On 7/30/24 4:51 PM, Brian Weis via Datatracker wrote:
> Reviewer: Brian Weis
> Review result: Has Nits
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> The summary of the review is Has Nits.
> 
> This document adds a “Compact Denial of Existence in DNSSEC” method
> to a couple of existing “denial of existence” methods using DNSSEC
> (i.e., NSEC and NSEC3).  Denial of Existence means “proving that a
> DNS name or record type does not exist”. It does this by returning
> a dynamically signed DNS response with this information.  A new RR
> type (NXNAME) is defined in the document, which is returned by a
> server with the “denial of existence” declaration.  This method is
> said to be smaller in size and requires less cryptographic computing
> than the previous methods, including when those methods dynamically
> sign updates.
> 
> With the caveat that I am not very familiar with DNS protocols,
> this document seems to have generally considered the security
> ramifications of the method. The risks of on-line signing of DNS
> records are covered. Additionally, the document states that this
> method “prevents adversaries from enumerating the entire contents
> of DNS zones by walking NSEC chains”.
> 
> Security Considerations also mentions that some security tools rely
> on particular return codes to detect non-existent domain names, and
> their current method may be impacted by this change. This is
> unfortunate, but I suspect that there was no clean way to accommodate
> those semantics in this design. It is noted that if security tools
> support this new method that they will be relying on signed data
> rather than the unsigned header to obtain the same information.
> Also, the document describes an optional header flag which a resolver
> that returns a different status. This seems to be intended to aid
> security tools, but perhaps if they’ve updated their tool to send
> a new header flag they would also be able to update it to accept
> the main method described in this document.  Is theres another
> practical reason for this optional feature? Or are the semantics
> of a resolver understanding both the old and new main methods just
> complicated and this makes it easier for them?
> 
> I’m a little confused by this statement in Section 4 (Response Code
> Restoration): “For non-existent names, implementations should try
> wherever possible, to preserve the response code value of 3 (NXDOMAIN).
> This is generally possible for non-DNSSEC enabled queries,
> namely those which do not set the DNSSEC_OK EDNS flag (DO bit).” I
> believe this is describing a case where the response does not include
> DNSSEC. Based on the name of the document that it was concerned
> only with a DNSSEC response, so it’s not clear to me why this
> suggestion needs to be made.
> 
> One general suggestion is that it might be helpful for the RFC Editor
> if there was an explicit note somewhere warning them that Section 6.2
> contains an (RFC TBD) self-reference that they’ll need to resolve.
> 
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]