Re: [DNSOP] signalling mandatory DNSSEC in the parent zone
Brian Dickson <brian.peter.dickson@gmail.com> Tue, 02 March 2021 17:25 UTC
Return-Path: <brian.peter.dickson@gmail.com>
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 673153A098A for <dnsop@ietfa.amsl.com>; Tue, 2 Mar 2021 09:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qffvL78wlRa for <dnsop@ietfa.amsl.com>; Tue, 2 Mar 2021 09:25:20 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605BE3A0989 for <dnsop@ietf.org>; Tue, 2 Mar 2021 09:25:20 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id d25so3979071vsr.11 for <dnsop@ietf.org>; Tue, 02 Mar 2021 09:25:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H9o8LZbZVQDT4qZDypIMTYGGw7/qvP55i8iubVz4/LM=; b=Cxj2YoeBeANhJ+F3hjXgJh0zcX2IWEOYUtmFiYzDCoVkSJFG1UdZ7fdB5TLGgM4ZYK g4uO3QfWoJde4XjxYyaFJkhgoW+FzvRf1ZbZvETg70rzn8lH1HBgGy9SPdkYjZOhZ9eS wvnCjunuofYnd3gDTMOuhH26CbymsHZafWCttJyiStP2zFPBuLE6gzB7OzeuDiesVAXX TCDGxJi6/qPOFLB4GdQDCRS2OLPrkT7sOaqdVyzFVDkJ+Opl/+beZo8vPEJrf9dq6zsq 2I9Z6GBso/z/kgQ0fYHt87s/O30LTbViydCGVryVs4YhULE4QbEKCerw8XzHl4Yem6/a Rk5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H9o8LZbZVQDT4qZDypIMTYGGw7/qvP55i8iubVz4/LM=; b=fB046pbflR3ZvgSrSDDEhTrr9c15os3Te7k+l2HUG+pz85x1AdI2AeB4Vg+S45HBFe yunNkej6rJyhUGySBzALpRhbhzuqR6NhUU3T7o2Xxlzr9J8BujQRtcOacn4Bf+yKtrto N41puCNTTCwMwnW0xvZmWaFC8YbI4tns1yiEhxJ1qlRKll6Ljv/amFzbK8YQL2LfgOcZ 5ikdeRrOR5COIODepHRu6J5RnQBUfPc+eQeNc7vOXX+FgchYQ8zNVAW66EwwLBKO8osR nIOEJ1/ySTdHfOMOMtO/YisqqWhme4LS4gWOQtNgFwFm/oGbKAo3pElCm2ZhyXJ2jL4Z S4Cg==
X-Gm-Message-State: AOAM531ChIIvcLX7395sFdQbfTXqfN7cta7WWV0jYNiY2H//8FuViqnf o7UdQMN5TBzU5kG0mGvA9guqdBD+8CRtjE0j/2o=
X-Google-Smtp-Source: ABdhPJyWUvGiMu8R5B/XU9Ku9yXUDcgCnxfbW4Oz5+L/Fy36vKtCv4+zJN4PmUhhpn3a2gkbKBQclysk2JMOUGjtjJ8=
X-Received: by 2002:a67:2c86:: with SMTP id s128mr3176093vss.12.1614705918673; Tue, 02 Mar 2021 09:25:18 -0800 (PST)
MIME-Version: 1.0
References: <20210301.205459.413147497474184552.he@uninett.no> <DE24E067-C0D3-4E26-B7FB-EF8311AE5E0A@isc.org> <5D1D786F-216A-4AD3-840E-CAFE5CA49B6C@wisser.se> <4577DCF6-9D72-4D46-90DD-F289F112E639@isc.org> <0FD37A06-9DD4-46EB-BBB9-C480155CC9F1@wisser.se> <430E9927-D129-4872-BC1D-BF1F8E924B63@isc.org>
In-Reply-To: <430E9927-D129-4872-BC1D-BF1F8E924B63@isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 02 Mar 2021 09:25:07 -0800
Message-ID: <CAH1iCirdEXZUsXRvr+623vk5v10WevmYjRsY_inJPd_j2P+Atg@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Ulrich Wisser <ulrich@wisser.se>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b307b505bc910434"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j2tTzkpKjq7UMHmu1kBMJHqKpVk>
Subject: Re: [DNSOP] signalling mandatory DNSSEC in the parent zone
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 02 Mar 2021 17:25:22 -0000
On Tue, Mar 2, 2021 at 4:47 AM Mark Andrews <marka@isc.org> wrote: > > > On 2 Mar 2021, at 23:06, Ulrich Wisser <ulrich@wisser.se> wrote: > > > > > > > >> On 2 Mar 2021, at 12:55, Mark Andrews <marka@isc.org> wrote: > >> > >> > >> > >>> On 2 Mar 2021, at 22:52, Ulrich Wisser <ulrich@wisser.se> wrote: > >>> > >>> @Håvard No, that isn’t sufficient. A resolver could have the old > DNSKEY set in cache but get signatures from the new servers. This can be > solved by cross signing the ZSK -> put the ZSK of the other provider in the > respective DNSKEY set, no need to exchange private keys, only the DNSKEY > records. Then you will always have a validation path. > >>> > >>> @Mark, that is exactly what I am talking about, a forced algorithm > change can only work, when both operators cooperate and if we insist on > lax-validation. We need both! > >> > >> It doesn’t even work then as there the signatures of the non DNSKEY > records are of the wrong algorithm. > > > > Why would the signatures of the non DNSKEY RRset need to be of the same > algorithm as the KSK? > > Lax-validation says that “any validation path” should be accepted. > > > > example.com. DS 123 8 2 xxx > > > > example.com. DNSKEY 257 3 8 xxx > > Example.com. DNSKEY 256 3 8 yyy > > example.com. DNSKEY 256 3 13 zzz > > example.com. RRSIG DNSKEY 8 … > > > > www.example.com. TXT “example” > > www.example.com. RRSIG TXT 13 … > > > > In my eyes there is a clear validation path to the www rr. > > It leads to bogus in a server that *only* support algorithm 8 because > THERE IS NOT AN RRSIG OF WITH ALGORITHM 8 > Rather than argue about this example (which may be incomplete and/or erroneous), let's try to "fix" the example, and clarify which algorithm is new, and which algorithm is old, including what is on each of the two servers in terms signatures and keys? (Clearly this cannot be valid to be on one server, given the DS and RRSIG(TXT) are not the same algorithm). I think the requirement for considering the addition, is the inclusion of both ZSKs in both instances of the zone, AND the publication of both DS records in the parent. If this happens well in advance of the change of NS record in the parent, what else needs to happen? And how is this handled by validators that handle algorithm 8 but not algorithm 13? If the example is expanded and corrected, I believe the answer should be, the algorithm 13 only zone is either insecure, or bogus, depending on the absence or presence of the algorithm 8 DS. I don't see a clean way to avoid a race condition between the NS records in the parent, and the DS records in the parent, given caching. This is likely why Joe Abley was suggesting going insecure for a brief period is the only way to avoid anyone getting "bogus" as a validation state. Algorithm 8 would go insecure permanently, while Algorithm 13 would go insecure for a brief period then go secure again. Perhaps the brief bogus for Algorithm 8 is acceptable, in which case the decision is really one to be made by the zone owner. Brian
- [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] DNSSEC Strict Mode Petr Špaček
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Samuel Weiler
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Brian Dickson
- Re: [DNSOP] DNSSEC Strict Mode Ralf Weber
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Brian Dickson
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Wes Hardaker
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode libor.peltan
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Joe Abley
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Wouters
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Samuel Weiler
- Re: [DNSOP] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Mark Andrews
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Paul Hoffman
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Bob Harold
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ben Schwartz
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Ulrich Wisser
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Joe Abley
- [DNSOP] Fwd: [Ext] DNSSEC Strict Mode Ulrich Wisser
- [DNSOP] signalling mandatory DNSSEC in the parent… Jim Reid
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ben Schwartz
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Paul Wouters
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] [Ext] DNSSEC Strict Mode Viktor Dukhovni
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Havard Eidnes
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ben Schwartz
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Brian Dickson
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Mark Andrews
- Re: [DNSOP] signalling mandatory DNSSEC in the pa… Ulrich Wisser