I'd like to suggest retiring the term "white lies." The term arose when describing minimal enclosing spans in comparison with maximal spans. In the original specification of NSEC3, spans between existing names were used in negative responses. The *purpose* of using the span was to authoritatively declare that the requested name does not exist. The maximum span was specified because all of the spans could be computed in advance of any query and included in the zone. The signing key did not need to be online. Having signing keys online was considered suboptimal security practice.
Very shortly after this specification for negative NSEC3 responses was put forth, the community discovered that maximal spans facilitated "zone walking" to find the complete list of delegated names, and this was considered to be a distinct security weakness. One of the ways to mitigate this weakness was to shift to using less than maximal spans in order to avoid disclosing the delegated names. Presumably any choice of less than maximal spans would have been equivalent, with minimal spans being an entirely sensible choice. (Or maybe I'm missing a specific reason for choosing minimal spans, but it's not relevant for the purpose of this note.) The resistance toward having online signing keys also shifted, and is now fairly common to sign negative responses as they are created. The term "white lie" emerged in the description of this revised strategy for creating negative responses as a way of noting that the response no longer matched the original specification as meaning the maximal span between delegated names. That made sense in the context of the discussions at the time, but it gave unnecessary weight to interpretation of the original specification. The original specification of the negative response need not -- and in retrospect, should not -- have meant the negative response was a maximal span. That was simply the way the negative response was implemented. So far as I know, there has never been an *intended* use of the spans to be related to the delegated names. That was simply a convenient implementation detail. If we separate the purpose of using spans from the particular choice of using maximal spans as a convenient implementation choice, there's no reason to consider minimal spans to be a "lie," white or otherwise. And for anyone reading current specifications or coming into this conversation now or in the future, using the term "white lie" will be confusing or a distraction. I think the term "white lie" should not be included in any current specification. If necessary, an Informational RFC explaining the history of the term could be written. For those who are writing standards track RFCs in the future and feel it is necessary to acknowledge the term "white lie" they can then refer to the Informational RFC. Readers focused on what they need to know in order to understand how negative spans work can ignore the distraction. Thanks, Steve On Wed, Feb 12, 2025 at 7:59 AM Deb Cooley via Datatracker <[email protected]> wrote: > Deb Cooley has entered the following ballot position for > draft-ietf-dnsop-compact-denial-of-existence-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Warren for the 'Cliff Notes' (they will be missed), and to Brian > Weis > for the early secdir review. > > Section 1, para 1: I did some RFC chasing. RFC4470 has no occurrences of > 'white lies'. RFC7129 does, but it is listed as "NSEC3 White Lies". I'm > guessing there is at least a typo here. I'm not knowledgeable about this to > understand (how entrenched the language is), but I suspect the use of > 'white' > here is unfortunate. [the use of epsilon later in the sentence implies > that > 'small' might be a good substitute.] > > Section 8, para 4: Is there a reference for the 'so-called Water Torture > attacks'? As a native English speaker, I know what that means, but it > isn't > clear to me that others will understand. > > Section 8, in general: No change required: I do think that this section > covers > the security concerns - exposure of private signing keys, denial of service > (both due to computation requirements and due to multiple queries), > transition > issues, and preventing adversaries from DNS mapping (although this is in > the > Intro). > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sent by a Verified sender
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
