Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Peter Thomassen <peter@desec.io> Thu, 22 June 2023 16:10 UTC

Return-Path: <peter@desec.io>
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 57793C1522A4; Thu, 22 Jun 2023 09:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=a4a.de
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 ArhRDLKt8HAL; Thu, 22 Jun 2023 09:10:15 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92662C1519A0; Thu, 22 Jun 2023 09:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2+mwvUwsk4h2nFm7+AYC4ZDsNARn5xIAOOexbBHrllc=; b=FTDJS2F07nv2pST7CL1JwSlY1D HUeLx078djOZZ6ZGqAjA6c2VbLR3hTpwuMA6IkK0ChoolU/i9NJAwM+7wmjpH9wiHGvz0KI9NqJxZ o9nAdD6AB8DBduMv8dBaJsJTNueeC22x0XuoqOBKTA8xeB/8jVWhGKtRgfGuxsWz+XnQH1JGeGZVW 1qU/rPSV2xceoaICkS/uNR+OP928myE1MGRMlmNaJ7H0V7CYGT9asIcIQx3n9zl1p6IwV8LQwvHse 8WYBaERWOujTXHfGp3bUiaPzJMRRAi7Kbcp2/2qd8ZIsItCLqpEWRPTVb1POFYR8tpGo8c2MEAuQu 43CH/rmw==;
Received: from [90.187.67.221] (helo=[192.168.55.171]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1qCMss-00Dd8h-Jq; Thu, 22 Jun 2023 18:10:10 +0200
Message-ID: <7b10d04d-6418-f608-2d5f-afc7c5c2e62a@desec.io>
Date: Thu, 22 Jun 2023 18:10:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: "libor.peltan" <libor.peltan=40nic.cz@dmarc.ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
References: <CADyWQ+HtK9LW8-HqSBdnPwidPz_yB1Obt=JR6dAFEMRLonGOyw@mail.gmail.com> <CADyWQ+G1RWUKe6KbO2cdf8YKQDFNDag1NHKXfEpfmj4irCmb8g@mail.gmail.com> <a636e396-0db8-2720-4cb3-11f52ef69571@nic.cz>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <a636e396-0db8-2720-4cb3-11f52ef69571@nic.cz>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PtcRS07pLbthP_nteSaixbw-PGo>
Subject: Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jun 2023 16:10:20 -0000

Hi Libor, all,

On 6/22/23 11:42, libor.peltan wrote:
> here are my comments to draft-thomassen-dnsop-cds-consistency-03.

Thank you very much!

> "In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were not part of the NS record set."
> 
> I don't feel confident about the consequences of this cathegorical statement. What if you have two DNSSEC providers, one has an outage (or just network breakage between them and the polling entity), and the other one maliciously takes over by publishing new CDNSKEYs? The polling entity might re-query several times from different locations, but this is usually only performed when bootstrapping the scure delegation, not when already established. And even if, it's not clear if (when) this would be enough. I understand, on the other hand, that relying on permanently disfunctional (or lame in any meaning of that word) child NSs might be problematic. To sum this up, if this is an issue in the proposed method, it should be fixed, and if it isn't, it should be more verbosely described why. The document seems too brief in this regard.

The SHOULD statement was added based on a concern Viktor voiced at one of the last IETF meetings, saying that if a nameserver is unreachable from the parent, this would permanently block DS maintenance. (A well-taken point, I think.)

I would expect the combination of a nameserver not being reachable and the other party being malicious to be quite a rare event. Given the probably much more frequent "price" of blocking DS maintenance, I think this is the right trade-off.

Where would you suggest to put more words about that? (Right there, or in the Security Considerations? Which words?)

> "CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with DNSSEC validation enforced."
> 
> Isn't this sentence disabling secure delegation bootstrapping?

Yes, good catch! I addressed it in this commit: https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/commit/7939107aebb4e4963367e1d7fd831d14f98dab27#diff-d3398566f77572362e657e31e035a0effbe92148ba122be28de37a177732f318

Also, I addressed all other comments received so far in response to the adoption call (commits in same repo). For convenience, see the editor's copy: https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/

Best,
Peter

-- 
https://desec.io/