[NCAP-Discuss] NCF phases x DNSSEC

Thu Dec 7 16:02:48 UTC 2023

My $0.02.

As Rubens mentioned, it is important to compare the behavior of the system with proposed NCAP changes to that of the system pre-changes.  In the case that these new delegations are not DNSSEC-signed, we would actually be going from signed (authenticated denial-of-existence proofs with NSEC from the root servers) to unsigned.  However, I'm not sure that that matters.  Since these queries are not legitimate (not intended to reach public servers), I'm not sure how an adversary might be targeting these unsuspecting parties.  It is within the realm of possibility, but I'm not sure there is much to gain.  But in the way of telemetry we have much to lose.

All that being said, I'm with Rubens, but I suggest that it's a SHOULD NOT for all tools.  After all, this is all about visibility of queries at the authoritative DNS servers, so whether it's "no interruption", "controlled interruption", "visible interruption", or anything else, the queries at the authoritative servers are what are telling us the names being queried.

Also, I wrote the following about this in my draft of Appendix 2:

"The zone contents above do not include DNSSEC records associated with the zone being DNSSEC-signed.  Signing the zone with DNSSEC is good practice, but a signed zone makes it subject to aggressive negative caching with NSEC and NSEC3 records.  This aggressive caching allows recursive resolvers to infer that a name does not exist without ever issuing a query for that name.  This mechanism is efficient, but it results in reduced visibility.  Three ways that this might be mitigated are:
	• Do not sign the zone with DNSSEC;
	• Rely on the 60-second TTL to mitigate the effects of all caching, including aggressive negative caching; or
	• Use an on-the-fly signing mechanism, such as that employed by Cloudflare. [1]

[1]  https://blog.cloudflare.com/black-lies/"

Thanks,
Casey

> On Dec 7, 2023, at 1:08 AM, Thomas, Matthew via NCAP-Discuss <ncap-discuss at icann.org> wrote:
> 
> Thanks Rubens.
> 
> Any other group comments?  Otherwise, I propose this is memorialized by the writing staff into the document.
> 
> 
> Matt
> 
> On 06.12.23, 22:23, "NCAP-Discuss on behalf of Rubens Kuhl via NCAP-Discuss" <ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org> <mailto:ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org>> on behalf of ncap-discuss at icann.org <mailto:ncap-discuss at icann.org><mailto:ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>>> wrote:
> 
> 
> 
> 
> Matt,
> 
> 
> Reflecting on that, I like your proposal. Collisions that are already happening do not have DNSSEC validation, unless someone uses old DNS software with TLV validation and an alternative DNSSEC chain.
> 
> 
> So while we already established as DNSSEC harmful to tool #1, so in this case is a MUST NOT, we could establish a SHOULD NOT for all tools from 2 to 4. And forecast root zone change rate based on “no DNSSEC needed”.
> 
> 
> 
> 
> Rubens
> 
> 
> 
> 
> 
> 
> 
> 
>> Em 30 de nov. de 2023, à(s) 05:59, Thomas, Matthew <mthomas at verisign.com <mailto:mthomas at verisign.com><mailto:mthomas at verisign.com <mailto:mthomas at verisign.com>>> escreveu:
>> 
>> NCAP DG,
>> 
>> Please see the note from Rubens. What is the groups thoughts on requiring or not requiring DNSSEC over the four phases?
>> 
>> My own opinion is that DNSSEC shouldn't be required or used throughout the whole assessment process under the "KISS" design principle. Maybe I'm wrong....but let's get some discussion going on this!
>> 
>> Matt
>> 
>> 
>> 
>> 
>> On 09.11.23, 01:09, "NCAP-Discuss on behalf of Rubens Kuhl via NCAP-Discuss" <ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org> <mailto:ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org>> <mailto:ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org><mailto:ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org>>> on behalf of ncap-discuss at icann.org <mailto:ncap-discuss at icann.org> <mailto:ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>> <mailto:ncap-discuss at icann.org <mailto:ncap-discuss at icann.org> <mailto:ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>>>> wrote:
>> 
>> 
>> 
>> 
>> Hi folks.
>> 
>> 
>> I wonder what’s the group take on whether each phase of the framework disallows DNSSEC, is neutral to DNSSEC or requires DNSSEC.
>> Let’s start with what we know, that phase 1 doesn’t allow DNSSEC (in order to avoid NSEC Aggressive Caching), and that phase 4 - considering its intrusiveness - requires DNSSEC (this was never discussed and is just my guess for now) in order to avoid (at least for the 50% of validating resolver queries out there) misdirection to a threat actor controlled honeypot.
>> 
>> 
>> With that in mind, what would be the requirement (or not) for phase 2 (response with private IP address)?
>> ( ) Can’t have
>> ( ) Better not to have
>> ( ) Could have, not required
>> ( ) Should have
>> ( ) Must have
>> 
>> 
>> Keep going: what would be the requirement (or not) for phase 3 (reset-all public IP )?
>> ( ) Can’t have
>> ( ) Better not to have
>> ( ) Could have, not required
>> ( ) Should have
>> ( ) Must have
>> 
>> 
>> My take is that phase 3 shares similar threat models with phase 4 and the must have DNSSEC applies there too.
>> On phase 2, it would be “not required” to me.
>> 
>> 
>> What’s the sentiment in the group for DNSSEC requirements, phase-wise ?
>> 
>> 
>> 
>> 
>> Rubens
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20231207/24aa3fa9/attachment-0001.html>