Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Daniel Migault <> Thu, 24 December 2020 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 942713A135C for <>; Thu, 24 Dec 2020 10:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fq0yM_8rjr78 for <>; Thu, 24 Dec 2020 10:29:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EB453A135B for <>; Thu, 24 Dec 2020 10:29:11 -0800 (PST)
Received: by with SMTP id j59so895338uad.5 for <>; Thu, 24 Dec 2020 10:29:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rZdVBoVvIcQGeCO92EbU2N0YvhR49V6rMpPXuxZ3KaM=; b=Y3xEOX7mWuF/m+yC/dJTvVcHw0bT7ayCRyipJ+yRfmyt5UQlPWs6YtOkXo3OpMDaZz xg6zskhG8yyJSXrU73Aj5Dxqhzq9jRNJjmaNJmxizUkputO5R24Tuh7OAYNvxsgXD1oM lOhJCYEtGHSPjm7CZg2Qu2kWSbnNWQqcyk43G1m2YlA0G47b7SBJ1yPAmy4N8mSLdMo9 txh3P6hqARG7JSETWZ1d3DRGxiC73PGJaMn9/K5Ytfp1G3kRH0nMldFVnZokMfjGCTch l3jOv9tNE8+4mxaJ9e+R5E/HDvZHKllWOf22UWOv+zQnsI4IoPfL2+mLjZwFj+mfis/x 6OcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rZdVBoVvIcQGeCO92EbU2N0YvhR49V6rMpPXuxZ3KaM=; b=mQ7shl8Hk0P7Z7/L9iDjhX9VYkYaB9rSxoMybvRDjoSIbA7cCApZyxMiY0Opoomz9z CzenSo+m30D9RifPJ+3txvunb+G8juQ5g9rq8L3FJtyveQsjs8HNHUt/4cHJnSTM7fIs rpgLvuRgAg1kc7yIVlS0+Q9pKoDpQ4VAbR1i+ePuHkyxpX6pY+w4hs58w6tvZTSmmmnP CDw++Vz6yLnNJzwHmXNyZGHQyz0yDayAQtuPa0zolMsPxtrjRC3M+3hmN5fpC+yzerL7 U/c9LT4LrQmXF3jFDs4n3kwaWSTCaQAFBx+3XMYjoC9fvL6d32Gf+2nr9FOe3OIuctlS lKew==
X-Gm-Message-State: AOAM532xv+0OfkbT6gh9V8z1BIWgR5XkDv6F1Ij5W4EnYQfS0I2+RSQu 3M7qD8GrddE+XmKEHdKyJgurpq7jemXMY/VALKU=
X-Google-Smtp-Source: ABdhPJwrsdM8GovO++EsnSs5zdK7W9xTdkePB0WOVS7X6RU6YL4MzYeRD1xuMywoX9QyHfa3/CJQ6F/I+qUZ1asMQNI=
X-Received: by 2002:ab0:49e4:: with SMTP id f33mr13780480uad.0.1608834550527; Thu, 24 Dec 2020 10:29:10 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Thu, 24 Dec 2020 13:28:59 -0500
Message-ID: <>
To: Paul Hoffman <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000e2fd8705b739fbea"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Dec 2020 18:29:15 -0000


As the DNS is a global shared resource and its reliability is based on
**all** pieces of software adhering a common standard, I am inclined to
believe that new cryptographic algorithms introduced with anything less
restrictive than "IETF Review" - such as "Specification Required" and "RFC
Required" - does not sufficiently prevent altering the interoperability of
the DNS.
This is likely to result in the introduction of potentially weak - and
unmanageable - cryptography, a fragmentation of the DNS name space, as well
as the introduction of policy matters within the IETF. Typically, some code
points will be qualified as **standard** while others will be
**non-standard**. This may put the IETF in a position to define that the
trust of community C1 in algorithm A1 is non-standard while the trust of
 community C2 in algorithm A2 is standard. I believe we should avoid this
In addition, I also believe that "Standard Track" is the appropriated
status. While a call for adoption of a cryptographic algorithm with a
"Standard Track" asks pretty clearly the community on whether they are
willing to see that algorithm being deployed. The same call for adoption
with another status is less clear and people may not feel concerned which
will make it harder to judge the consensus. It is also envisioned that
calls for adoption will have an extra round of discussion over the status
which I am not sure is necessary.

As a result, I am inclined to believe we should not adopt
draft-hoffman-dnssec-iana-cons and we should re-evaluate RFC6014.


On Fri, Dec 11, 2020 at 11:35 AM Paul Hoffman <>

> On Dec 11, 2020, at 8:26 AM, Tim Wicinski <> wrote:
> >
> >
> >
> > This draft was present at IETF108 and IETF109. There was interest in
> adopting this, but I do recall that implementors had some concerns about
> this.  However, there was enough interest in starting an adoption
> > call on this.
> >
> >
> >
> > Because of the holiday, I'm going to run this call until the 31st, to
> allow folks to discuss.
> >
> > This starts a Call for Adoption for:  draft-hoffman-dnssec-iana-cons
> >
> > The draft is available here:
> >
> > Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, review, etc.
> >
> > This call for adoption ends: 31 December 2020
> I'd like to see this adopted by the WG so that the GOST document can
> proceed forward. I'm also quite interested to hear input from developers
> about how they feel affected by the different options for documentation of
> algorithms for DNSSEC.
> --Paul Hoffman_______________________________________________
> DNSOP mailing list

Daniel Migault