Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Paul Wouters <paul@nohats.ca> Mon, 04 January 2021 16:05 UTC
Return-Path: <paul@nohats.ca>
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 4E33C3A0E3F for <dnsop@ietfa.amsl.com>; Mon, 4 Jan 2021 08:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 gKtqXnPQX77d for <dnsop@ietfa.amsl.com>; Mon, 4 Jan 2021 08:05:40 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9153A0E74 for <dnsop@ietf.org>; Mon, 4 Jan 2021 08:05:39 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4D8gTF2LNMzFCP; Mon, 4 Jan 2021 17:05:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1609776337; bh=xZAazgesxCsGXdgPCKSvlVAFzgSdoYAdTw9WBwMzSOA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B/G68H9EwhwOgoBRWuNSfh+Oi3woAbQMZe5puIa10gS9B/c8KEaKpf8NQeXEM7XR5 15Bxjvxy+iUWjpLStiyqKauhAs8LSmFYZC6bWcJ0/cnYB/kcSPj8NdpTIZYQaLEE01 hhKNvBPhPMhXE3UEBGCCi5uxT2bWimYXfjJ3VmDU=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id POdBiW3A8stY; Mon, 4 Jan 2021 17:05:35 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Jan 2021 17:05:34 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D713D6029BA0; Mon, 4 Jan 2021 11:05:30 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CE34266B7C; Mon, 4 Jan 2021 11:05:30 -0500 (EST)
Date: Mon, 04 Jan 2021 11:05:30 -0500
From: Paul Wouters <paul@nohats.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
In-Reply-To: <ebb27f27-a243-67cd-2b5c-d2ecea741942@cs.tcd.ie>
Message-ID: <24505bb1-cf40-25a7-337c-9b50fedfedc1@nohats.ca>
References: <CADZyTkn1QuvjencR8+wVtQ9bzQHJT9JXXNku1LPr3YRmRt4KQg@mail.gmail.com> <2E8229BE-E764-4C29-A258-8C469717E38A@nohats.ca> <CABcZeBMr5Muijx5V7Se1UcxTB9DbAzF1iXZb7_FzEGfw982x8w@mail.gmail.com> <65e3288d-bdfe-ff10-2fbc-63a5d2dd9508@cs.tcd.ie> <797AAE77-2D50-4189-81D8-44BA495146F5@icann.org> <546e60c6-b109-8552-dfb4-7d3ba2ecbc71@cs.tcd.ie> <E58B4013-9491-43ED-83C9-250FF7647570@icann.org> <0746397c-ed85-429c-ff6e-a4a559520e86@cs.tcd.ie> <487928351.1557.1609759876775@appsuite-gw1.open-xchange.com> <60ba1f68-b07f-7a06-539f-60ce442ffbff@cs.tcd.ie> <195eb4c7-306f-97e1-b0df-f6678ebe732@nohats.ca> <ebb27f27-a243-67cd-2b5c-d2ecea741942@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y0X-S9SjCVg7uBt4_J3EFKlb0A4>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
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: Mon, 04 Jan 2021 16:05:48 -0000
On Mon, 4 Jan 2021, Stephen Farrell wrote: >>> WRT GOST, we're not really talking about an algorithm but >>> rather a national crypto standards scheme that selects sets >>> of algorithms. For such things, whether from Russia or the >>> US or anywhere, I think it's quite fair to ask "how has >>> version N deployment gone?" >> >> Why is that fair? > > Eh? Seems to me that asking about the facts is fair. > I have a hard time envisaging a way it could be unfair > tbh, so your question surprises me. While asking is fair, you would also have to define what you do based on the outcome of that ask. You left that out, so at best I can interpret is that you would partially base any IETF decision about algorithm N+1 on results of algorithm N. >> I'd say the community was quite busy and >> possibly made some mistakes in the past. I don't think that >> is a valid barrier for the future. For example, would we >> bar NIST or the US from ever standarizing a new RNG? :P > > You seem to be assuming that the goal of asking is to > justify saying "no." That wasn't my intent - I just think > we make better decisions if we know the deployment facts, > rather than our decisions being based on whomever is > good at rhetoric or automatically giving nation-states > or mega-companies whatever they ask. But that brings us back to the original issue, what are the requirements for getting an allocation? If it is "with IETF approval that includes a history of your previous work", then that is pretty close to IETF doing a full evaluation, AKA the path of Standards Track. This again puts the IETF in the middle of nation state crypto politics. We should not want that. Now if you said nation states get at most one allocation per 5 years or something equally neutral and measurable, then I might agree. But in that case, I think Tim's solution is a better one that accomplishes the same - give out a chunk of numbers, but hold on to a bunch for true international / IETF usage. > WRT a new RNG - yes if one was suggested from a US or > any source, then we absolutely should be very careful with > that. Mind you, I can't think of an iana registry that > has RNG algs as entries so maybe it's not a super-good > example. But you understand why I use it as example. It would be the equivalent of asking the USG/NSA/NIST about their "algorithm N" as part of considering "algorithm N+1". For example, IETF declaring SHA3 a "nation state algorithm". (the tricky thing here is that the US seems grandfathered in as a non nation state entity on those occasions when it is) >> If a national government wants something, we could ask for >> at least one implementation to be planned. > > That was not what I suggested asking. I'd just like to know > if or how much the current gost stuff gets used with dnssec. What is the relevance of this, if not to take it into account of the decision making process of N+1 ? Should the failure of adoption of RSAMD5 in DNSSEC have been used to evaluate RSASHA256 ? The early code points in DNSSEC suffered from the general lack of DNSSEC deployment at the time. I'm sure that is as valid for RSAMD5 as it was for GOST. The lack of these deployments where unrelated to the algorithm. As to answer your question, I believe GOST did not see more than about 5 domains use it in what was clearly a "Testing" deployment. >> But on the other side, if would be nice if we could become >> faster with obsoleting algorithms too. Why is there still >> RSASHA1 deployed.... > > Yep. Allocating codepoints for things that don't get used (if > that is the case with gost algs and dnssec which I *still* > don't know any more about), doesn't help us move on from > things that did get used. This is where we fundamentally disagree. If a government asks for a codepoint, they don't do it so it does not get used. Clearly, the intent is that it will be used. Whether that will be true in the future might be hard to say for either the requester of the code point or for the IETF. This is very different from say me as an individual asking for a (likely vanity / unwise) code point. Paul
- [DNSOP] Call for Adoption: draft-hoffman-dnssec-i… Tim Wicinski
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Daniel Migault
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Vixie
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Olafur Gudmundsson
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Tim Wicinski
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Valery Smyslov
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Daniel Migault
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Daniel Migault
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Daniel Migault
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Eric Rescorla
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Stephen Farrell
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Stephen Farrell
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Stephen Farrell
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Vittorio Bertola
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Eric Rescorla
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Stephen Farrell
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Stephen Farrell
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Vixie
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Jim Reid
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Stephen Farrell
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Jim Reid
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- [DNSOP] Code Point Assignment Suggestion - was Re… Brian Dickson
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Василий Долматов
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Ben Schwartz
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Василий Долматов
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Ben Schwartz
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Joe Abley
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Ben Schwartz
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Joe Abley
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Jim Reid
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Ben Schwartz
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Eric Rescorla
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Hoffman
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Paul Wouters
- Re: [DNSOP] [Ext] Call for Adoption: draft-hoffma… Eric Rescorla