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