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

Eric Rescorla <> Thu, 31 December 2020 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F5F23A0C03 for <>; Thu, 31 Dec 2020 13:49:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 v_q8sqHCvJW3 for <>; Thu, 31 Dec 2020 13:49:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 258553A0C00 for <>; Thu, 31 Dec 2020 13:49:15 -0800 (PST)
Received: by with SMTP id o13so46353162lfr.3 for <>; Thu, 31 Dec 2020 13:49:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QJmpUzsc04QqP73V+GW8Ida9TAytlL+7Jc7/Rq55Inc=; b=dYwNltnCmcMN7HKzEjKzWUTvDhB8p7G+8NZPsQ215lk0JHsJroiWamGbrXBnqTs5yZ 2ElSeDiu8tUaE5F8UIM6m62VC8vYxTmxQbzM9U0Rr267t0RsacH7MTKLebYYybctAKlC rCXAN+SA4osKWpl0ODmcopoPHr8vsIVfdhQJcj/J7WzjhNlmwsvnJz/xAGsgL3Tg0Td3 7oLsDFxTE5LAksd+kfAS6Wgrf2yLGXZIC7xNyj9Xt4ma7klXvmI0++8L5bNymKHuAgeB 278cq7GTtDMXcL85YOx4bIhKRGiTr8Kxxg84uPMFXcx/7r6OhtbJM46kkX+etXDEEVpN j98A==
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=QJmpUzsc04QqP73V+GW8Ida9TAytlL+7Jc7/Rq55Inc=; b=XoKg/a+mKrTHQaT0XBuvFxxq5NjQZYihsTtkytvBSUZC6/nJVbar35A4nIGy4wG7dc XS4wulsZVkbnq9DSIg5bb+/mdU4drlPNFMzaLxgsuEl8PKM7RdHiacb5ODgAmy+5ftXK cY0Gn0dRS59SWTk53ZFEQHOXE1PwIIC5vKqx/bCDEyw/nOYaPzPy9R2yvqxvjtuA18eU vO5RCmKsyWaAWOYZEsCvY/nHKkRXwBHsIvKBYTKnnlllmRjOZPKbmmrIKFkP63XIQj9j 7v+MwKVoLf4IeBTEDg3HRCqTXE9tAU2SN4wtQJ9ZFfmZulkt9H8lVhysAUHPoBpf//k9 uYNw==
X-Gm-Message-State: AOAM532cmVsaic5BecEdPqM2Q9mls+0EorMSi94OWaUUfdfo25z1gh07 bs4EtVJfKG/c/zSa4Q+ANS8KCJrDPHgFRxHeVYXsdw==
X-Google-Smtp-Source: ABdhPJyAQYp7R2xHrCnrDB/U9EfzndRyI7gcKbrEcX5LXz+gEwhnNeu+k5PBTzibOJTvlVtxbpcV0ToT8Mn9T37l4xc=
X-Received: by 2002:a19:6447:: with SMTP id b7mr26106446lfj.206.1609451353159; Thu, 31 Dec 2020 13:49:13 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 31 Dec 2020 13:48:36 -0800
Message-ID: <>
To: Paul Wouters <>
Cc: Daniel Migault <>, Paul Hoffman <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000304d7005b7c998b2"
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, 31 Dec 2020 21:49:17 -0000

On Wed, Dec 30, 2020 at 7:23 PM Paul Wouters <> wrote:

> On Dec 30, 2020, at 22:11, Daniel Migault <> wrote:
> >
> > 
> > <mglt>
> > If I understand clearly the comment, it seems to say that TLS ( for
> example ) is using RFC Required and that DNSSEC should do the same. Quickly
> going through RFC 8447, I cannot find "RFC Required", so I am wondering if
> you have a specific registry in mind. As far as I can see, the TLS cipher
> suite registry requires Standard Action to set Recommended to "Y" and
> Specification Required otherwise. As a result, leaving it to Standard
> Action seems better aligned with what TLS does for "Recommended".
> As previously explained in this thread, you cannot compare TLS with
> DNSSEC. With TLS you can offer IETF algorithms along with a nation state
> algo, and the client can pick what it prefers.
> For DNSSEC, the signed zone has already made all the decisions. A DNS
> client cannot decide to use or not use its local national algo.
> Paul
> > My motivation for not lowering the requirement is based on the
> specificities of DNS, that is the DNS is a system handles a global shared
> resource
> For those regimes who for instance are not allowed to trust RSA or
> NIST/NSA based ECC curves, you prefer those zones use no DNSSEC at all
> versus say GOST ?
> Because that’s what you are offering as the only choice now.

Thanks for making the point so sharply, Paul.

To be transparent about my priors, I think it would be better if
people used one of the more typical IETF algorithms, which is to say
ECDSA or EdDSA [0]. With that said, for whatever reason there are
people who want to use some other set of algorithms and the IETF's
ability to discourage them is limited. The IETF really has three main

1. Don't allocate a code point at all
2. Allocate the code point but in some manner that makes clear
   we don't endorse it (effectively what TLS does for algorithms
   like this)
3. Allocate the code point without comment

My general sense is that (1) and (2) do to some extent discourage the
use of these algorithms (with (1) being more effective than (1)) but
(1) may discourage them *entirely*, so the likely result is that
people who want to use them just squat on a code point (or worse,
multiple code points!) and we lose those code points anyway, but
potentially after some interop problems. It's for this reason that
I think (2) is the best approach here.

As a number of people have noted, DNSSEC is different from TLS, IPsec,
etc. in that there's no real opportunity to negotiate. I don't think
that this changes the basic calculation but it might make it worth
investing more effort in discouraging people, both to prevent
algorithms that we think people should avoid and to reduce sharding of
the ecosystem if, for instance, some implementations opt not to do
algorithm X. It might also make it worth spending more effort in
helping people get good definitions of algorithm X even if we don't
think they should use it (as opposed to with TLS where the response is
mostly "go ahead and register, but don't bother us"). I'm skeptical
that "RFC Required" would foster either one of these goals, but
perhaps that's what Daniel is arguing?


[0] I think we should discourage RSA.