Early Review of draft-ietf-dnsop-compact-denial-of-existence-04
review-ietf-dnsop-compact-denial-of-existence-04-secdir-early-weis-2024-07-30-00
Request | Review of | draft-ietf-dnsop-compact-denial-of-existence |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Early Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-07-31 | |
Requested | 2024-07-06 | |
Requested by | Tim Wicinski | |
Authors | Shumon Huque , Christian Elmerot , Ólafur Guðmundsson | |
I-D last updated | 2024-07-30 | |
Completed reviews |
Dnsdir Early review of -01
by Nicolai Leymann
(diff)
Secdir Early review of -04 by Brian Weis (diff) |
|
Comments |
Preparing for WGLC would like some good Security Review |
|
Assignment | Reviewer | Brian Weis |
State | Completed | |
Request | Early review on draft-ietf-dnsop-compact-denial-of-existence by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/SMBp-9OPyOplxT1ZOtUXG2LULYo | |
Reviewed revision | 04 (document currently at 05) | |
Result | Has nits | |
Completed | 2024-07-30 |
review-ietf-dnsop-compact-denial-of-existence-04-secdir-early-weis-2024-07-30-00
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.