Re: [DNSOP] [Ext] More private algorithms for DNSSEC
Brian Dickson <brian.peter.dickson@gmail.com> Wed, 30 March 2022 03:29 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 4B6D13A08AE for <dnsop@ietfa.amsl.com>; Tue, 29 Mar 2022 20:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 NAMr6AIJB0o9 for <dnsop@ietfa.amsl.com>; Tue, 29 Mar 2022 20:29:19 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 400673A08A1 for <dnsop@ietf.org>; Tue, 29 Mar 2022 20:29:19 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id yy13so38884450ejb.2 for <dnsop@ietf.org>; Tue, 29 Mar 2022 20:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=86hRmCQl6AG+5WAHvh2oRM9I/V6R3rGmsP4aeMK4GXE=; b=HpDixofs1JPWEqZq0c2cGJN+ArBEGqliUXHbz29x1EtUooV6z5ll7D12GMdCk5ud4b tflUfhRlaTPnkYJ+5ZT72etB8jt1mk2QWDwEs7davKE0OsXHer9Nz68+FXXf3PdvaD+Z D2kxvGZoPuAwtFa8l8BnPbFwPpsW5IoaI9rx2dLKswd3HhxvPihun6RiJGCon/Kg1tSA k0guP8sNi0J/eukpb3TtMOhNkiPnGB6bfWCOGpr/IXd1ziYwELC6PnWdjc+iR1DbmsR0 IoCzqzhc+GcGva+tWqITOppvcHPrylS113VC6o4i8CfRqSxCCK9Ku//U+nkCn3vIUizL 1vvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=86hRmCQl6AG+5WAHvh2oRM9I/V6R3rGmsP4aeMK4GXE=; b=RGLzmBIRXeY8w0wOuXmXaqxlhFYY7CA13T9NmuEG8p2tmKHhCVv33hlWNbbY4Q3fad MEda/K2zG4Pksq//7bkxxEsxMT4JwcmsMa7TT3I8Kh58er6GwEA1mZ7rVuaJ/H6/7tuM 9DcHJ2VnkBz3lJx95V6BvM/lUxKLoXxKGBKxNza3BJ4UNkzBsgtuguMfJsyPbwVq7x9r H6ZPqZkkb3LiHrB/gLVJWraYvVhf1Kh4jSC/jAoL6eokrGHwZ6x5Y4l4eWgVqBShGOUp i6Z3fDrn8k0LhgMusabb5XiPBmJNx2fGajQ/TWqIMc5EYkK2Ujhmm+oO29OPLpJoGJhm 1Low==
X-Gm-Message-State: AOAM533k1nTNUjMuVYepFyyL1EA+bD5/SfISWJILp2b/IJPHbUVcWDJ5 eiy9gzR12+f4Rr4T7l0xR44Y9q5mNWg9KyelLbXt7MiN
X-Google-Smtp-Source: ABdhPJx41wnpWeRK7gAbPUELSfD4v9m6OLRdi4AXPmc1UHum+ZDFgnLOB8tv3AQlxu4RrfhHnErxfD1mobxBTEyGmcg=
X-Received: by 2002:a17:906:7316:b0:6d7:16be:b584 with SMTP id di22-20020a170906731600b006d716beb584mr37682166ejc.759.1648610957426; Tue, 29 Mar 2022 20:29:17 -0700 (PDT)
MIME-Version: 1.0
References: <5C105C71-B18C-4366-94F5-E8D60970109C@icann.org> <20B389EF-4909-43A0-9BC8-F57F5E332E8A@verisign.com> <1D59C3FB-4FCC-4A03-8E13-EA6902B14D2A@icann.org> <54622bd0dd3253187a9c9b69d0a1188a4d898bd9.camel@powerdns.com> <CC878AFE-3B67-49D9-9A9E-F3D21BC900FB@isc.org> <6859EF89-8E3A-4C18-8B4A-2AF4C37CDF65@icann.org> <585479E8-293C-42D4-BA2F-7FD99B27EBDE@isc.org> <c3a7bfb5-9e43-ca40-8b15-7f84a2826022@desec.io> <C78A56E8-E4F6-40A4-8C1B-32738A53518D@isc.org>
In-Reply-To: <C78A56E8-E4F6-40A4-8C1B-32738A53518D@isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 29 Mar 2022 20:29:06 -0700
Message-ID: <CAH1iCio6KjeJS1oL_Q=jcLNKsjO458Z49T6B9F_JQ8dMdT0pZg@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Peter Thomassen <peter@desec.io>, Paul Hoffman <paul.hoffman@icann.org>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007d835b05db67266c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Q6wwkZClKbJbpkvUbEpfWY6KbBI>
Subject: Re: [DNSOP] [Ext] More private algorithms for DNSSEC
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: Wed, 30 Mar 2022 03:29:25 -0000
On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews <marka@isc.org> wrote: > > > > On 30 Mar 2022, at 00:28, Peter Thomassen <peter@desec.io> wrote: > > > > > > > > On 3/28/22 20:34, Mark Andrews wrote: > >> About the only part not already specified is matching DS to DNSKEY > using PRIVATEDNS but as you can see it is obvious to anyone with a little > bit of cryptographic understanding. > > > > That creates problems plus complexity, which I find very undesirable. > Orthogonality trumps complexity. > > > > For example, zones need to have a DNSKEY for each signing algorithm > given in the DS record set. I would expect most implementations to > currently only look at the algorithm number in this context, and not at the > 253/254 algorithm identifier. > > And if they don’t implement any PRIVATEDNS or PRIVATEOID algorithm this is > EXACTLY the correct behaviour. > You (Mark) are arguing that any experimentation would turn 253 in to a MUST IMPLEMENT. I think the other arguments (about having multiple algorithms allocated for experimental usage) is more persuasive, including the nature of multiple algorithms when experimentation is done. This also keeps the 253 use case (actual private production use) distinct from experimentation usage, thus preventing any negative interaction between experiments and production zones. (It's not about whether the behavior is correct, it's about whether there is value added in selecting the 253 mechanism rather than reserving experiment-only code points, IMHO.) > > > There will also be implementations which don't care to implement such > "private algorithm peeking". For those, algorithm handling would not be > ensured in the same way as it is for non-253/254 algorithms. > > Then they would be broken which by the way is why you run experiment. This presupposes that only 253 is used, rather than what Paul H has proposed in his very small draft. It's a moot point and not contradictory to the proposal, to not want or need to do the peeking bit (i.e. not supporting 253). > > Last, I'm not convinced that running a PQ algorithm (or other) > experiment to test (non-supporting) resolvers' behavior should require > controlling a domain name or OID (as is required for 253/254). > > So rather than that you want to have to deal with potential colliding use > of code points without identifiers. > You can’t > reliably clean up experimental code points, especially if there are a lot > of implementations. DNS has a long tail. > > > These concerns bring us back to Nils' comment that 253/254 is not a good > basis for performing research and doing real-life experiments. > > > > > > The above headaches would be in addition to the effort of writing the > clarification document, whereas Paul's proposal requires just the document. > > DNSSEC RFC say check the algorithm for a match. They do not say check the > number. PRIVATEDNS and PRIVATEOID are sub typed > and checking of those fields was always required once you implemented an > algorithm in those spaces. > Everyone else is saying, we don't want this to be the way of doing experiments (with lots of good reasoning behind that). The "once you implemented" is a conditional that is not mandatory to implement. There is also guidance now that sub-typing is not a good idea for anything new in DNS. I'd suggest that your argument is in fact suggesting the use of sub-typing for something new (experiments rather than just private use) in DNS. > > > I therefore support the assignment of experimental algorithm numbers, > and I think the text should mandate that they MUST be treated as unknown > and have no special processing, unlike private ones. > > Stop calling for polluting of the commons. We can’t properly cleanup > after using experimental code points. > I think it is sufficient to reword Paul's proposal, so that the 7 new code points are labeled "experimental" rather than "private use". A few words about expected behavior of implementers ("Don't release production code with these code points in use", along with "ship production code to explicitly disallow use of these code points".) DNS hasn't previously had explicitly allocated experimental code points for algorithms, so how those do and do not get used probably needs some minimal guidance. I don't know if that belongs in this document, or as a separate document. My instinct is "separate", and also that such a document doesn't need to be a blocker on Paul H's document. Maybe it is necessary to add some sort of explicit signaling about use of experimental code points and that software involved in a particular conversation (server or client) is in experimental mode. The (potentially really bad) idea that occurred to me was, there's a currently unused bit in the header, "Z", which is a vestigial remnant of the larger Z field of "must be zero" from 103[345]. Perhaps that bit could be re-labeled "X" (for experimental)? Experimentation, including interoperability is a good thing. Leaving past experiments' code assignments (from the experimental range) is a bad practice, which should be self-limiting in nature. As long as production software knows to ignore that range, and treat those code points as "unknown", the only time a problem can occur is if a client and server in production BOTH have made the error of shipping production code that understood specific code points. Unit tests and regression tests for this should be the first thing implementers write, before they write a single line of code to implement experimental functionality, IMNSHO. Putting the correct sorts of "SHOULD NOT" and/or "MUST NOT" advice in the short document is probably all that is required. The shorter and simpler the doc, the easier it is to point implementers at it and say, "fix your code". Brian P.S. If I haven't already said it yet, I support use of new code points for experimentation.. They should be labeled "experimental" with guidance that the experiments are themselves private in nature, and that no production code should ever treat those code points as known or valid.
- [DNSOP] More private algorithms for DNSSEC Paul Hoffman
- Re: [DNSOP] More private algorithms for DNSSEC Paul Wouters
- Re: [DNSOP] More private algorithms for DNSSEC Wessels, Duane
- Re: [DNSOP] [Ext] More private algorithms for DNS… Paul Hoffman
- Re: [DNSOP] [Ext] More private algorithms for DNS… Nils Wisiol
- Re: [DNSOP] [Ext] More private algorithms for DNS… Mark Andrews
- Re: [DNSOP] More private algorithms for DNSSEC Peter van Dijk
- Re: [DNSOP] More private algorithms for DNSSEC Petr Špaček
- Re: [DNSOP] More private algorithms for DNSSEC Nils Wisiol
- Re: [DNSOP] [Ext] More private algorithms for DNS… Vladimír Čunát
- Re: [DNSOP] More private algorithms for DNSSEC Mark Andrews
- Re: [DNSOP] More private algorithms for DNSSEC Nils Wisiol
- Re: [DNSOP] More private algorithms for DNSSEC Mark Andrews
- Re: [DNSOP] [Ext] More private algorithms for DNS… Paul Hoffman
- Re: [DNSOP] [Ext] More private algorithms for DNS… Mark Andrews
- Re: [DNSOP] [Ext] More private algorithms for DNS… Mark Andrews
- Re: [DNSOP] [Ext] More private algorithms for DNS… Peter Thomassen
- Re: [DNSOP] [Ext] More private algorithms for DNS… Mark Andrews
- Re: [DNSOP] [Ext] More private algorithms for DNS… Mark Andrews
- Re: [DNSOP] [Ext] More private algorithms for DNS… Brian Dickson
- Re: [DNSOP] [Ext] More private algorithms for DNS… Mark Andrews
- Re: [DNSOP] More private algorithms for DNSSEC Blacka, David
- Re: [DNSOP] More private algorithms for DNSSEC Mark Andrews
- Re: [DNSOP] More private algorithms for DNSSEC Nils Wisiol