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

Michael Sinatra <michael@brokendns.net> Wed, 31 July 2024 15:50 UTC

Return-Path: <michael@brokendns.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880C0C151063 for <dnsop@ietfa.amsl.com>; Wed, 31 Jul 2024 08:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brokendns.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-IMQtO1qsBa for <dnsop@ietfa.amsl.com>; Wed, 31 Jul 2024 08:50:29 -0700 (PDT)
Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69323C14F6F0 for <dnsop@ietf.org>; Wed, 31 Jul 2024 08:50:29 -0700 (PDT)
Received: from elwha.brokendns.net (elwha.brokendns.net [206.125.172.202]) by burnttofu.net (8.18.1/8.18.1) with ESMTPS id 46VFoRtm049719 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 31 Jul 2024 11:50:28 -0400 (EDT) (envelope-from michael@brokendns.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brokendns.net; s=bt; t=1722441028; bh=AJXQ5Xq//2o71jdcxuUKJX8FUzdFFgi+6OG4jOMjIEk=; h=Date:Subject:To:References:From:In-Reply-To; b=imaFbVD8C/wGZ0b3xyYvdOR+TUw/lk4KmcNlSRfrIlLeZXiHqwaT3lld6Kmlwkbu1 VsgkXZat+w3mc45FAaBx1SRuNFOpjOGfn6a0r4w0hgVpCiCr3q6Dwf0m0W01BMextj aFB705JLGy3mJAe5fyQ/nxxkY9HM6gScyk2JV1jm/Oe4jML65ArV4suhyxyVRrDCqx Q37dvokXbaMiY1J/P4QWlvZfwQxQGFPRR4+cPh6N3rxwvz3l5JTbg8xp+EVtapDMWR szqzcKOZsyZFT1hzSY2PMb0eHxMyw1kQIvJ/Murv+INXFlIJJuXvlINFVNRLoy7bWX FvFzewQuQ+TsQ==
Received: from [IPV6:2620:83:8004:572::1:959] (unknown [IPv6:2620:83:8004:572::1:959]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id CFD00728D; Wed, 31 Jul 2024 08:50:26 -0700 (PDT)
Message-ID: <eba35d19-7a0a-4a0c-bb36-830f2088658a@brokendns.net>
Date: Wed, 31 Jul 2024 08:50:26 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: John Levine <johnl@taugh.com>, dnsop@ietf.org
References: <172238346320.1988233.11549951810315868557@dt-datatracker-659f84ff76-9wqgv> <d62f53f0-fe73-4e35-84cb-ddda704a73eb@brokendns.net> <CAHPuVdXYqoKjeO18kXoud2YO6KO_FL=m2xSjqQ7QdwV2mLi8Qg@mail.gmail.com> <20240731024049.63B049098839@ary.qy>
Content-Language: en-US
From: Michael Sinatra <michael@brokendns.net>
In-Reply-To: <20240731024049.63B049098839@ary.qy>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: USCLWJTHNTWAIIFODD64HLOLAODHDPZE
X-Message-ID-Hash: USCLWJTHNTWAIIFODD64HLOLAODHDPZE
X-MailFrom: michael@brokendns.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Secdir early review of draft-ietf-dnsop-compact-denial-of-existence-04
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ag4A24_1uUEr0g53nzAjwHDD-D4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>


On 7/30/24 19:40, John Levine wrote:
> It appears that Shumon Huque  <shuque@gmail.com> said:
>> -=-=-=-=-=-
>>
>> Thank you Michael,
>>
>> Your observation is certainly true. However, I want to point out that
>> inability to
>> synthesize NXDOMAIN via aggressive negative caching applies to any online
>> signing scheme that uses minimally covering NSEC, not just Compact DoE.
> 
> It's also what happens with no DNSSEC at all, give or take larger
> responses. I think we can agree to note it but there's nothing to do
> about it.

Exactly--that's all I am asking.

> I have to say it's amusing that now it's a security issue *not* to
> implement RFC 8198.

I'd say it's more of security trade-off becoming more apparent than a 
security issue per se.  These kinds of attacks have evolved to the point 
that they're making really "good" use of the public resolver (as well as 
private resolver) infrastructures, so aggressive ncaching can now really 
make a difference.  It's certainly not in the scope of your draft to 
explain mitigations for this particular type of attack, my only request 
is that you are clear that this solves one set of problems (reducing 
computational load for online signers while still preventing 
zone-walking), but that other considerations are *explicitly* out of scope.

My motivation is that I have seen in my industry some knee-jerk adoption 
of things like NSEC3 without a full examination of the trade-offs.  So I 
am not proposing any changes to CDoE; only that your RFC gives people 
the opportunity to make informed decisions about what to use.

> When I suggested NXDOMAIN synthesis twenty years
> ago as a way to speed up sparse IPv6 DNSBL queries, the dnsop crowd
> firmly told me that I was an idiot even to propose it, and the only
> valid approach was to get nice fresh answers from the authoritative
> servers each time.

Totally agree with the sentiment.  I didn't think much about the value 
of NXDOMAIN synthesis one way or another until the last couple of years.

michael