Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

Roy Arends <> Wed, 15 March 2017 10:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AB00129AA3 for <>; Wed, 15 Mar 2017 03:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ELA3zTz5036J for <>; Wed, 15 Mar 2017 03:26:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8EEE129A9F for <>; Wed, 15 Mar 2017 03:26:20 -0700 (PDT)
Received: by with SMTP id t189so19067456wmt.1 for <>; Wed, 15 Mar 2017 03:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=V5avveUwIOQabihmWQtv4qy3K8OjgFj5bCI8DQS7S10=; b=STf0JtA6Rdg1xpa2tjgqfpIEOAhg5TGfcy1rAl2yE0edWBYLPJ2S/alIiu+3PnfJpA A06rT6n8ZWYH+7W90dGbZXvXujnPM7I38kLVJ23vec6HPq32EhaElQhrLCrlM7Qp5iri mag4rKpblNAWptN0/BXLwa3OnB4ZeGAyXlv+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=V5avveUwIOQabihmWQtv4qy3K8OjgFj5bCI8DQS7S10=; b=Ppje51z6i18f4/EsJeorr3MQWVslD1FFeQ58Qo9rsYjidN9YRvf2SKJjhAzJaR864F weQ4fhWQ9ISC9XZhETkRPSTcUhI+T+Gylr7IH5PnZEC6w9i+YaU+dYs7tda6zZg5qcPL gcUeGdbf4SM+SVbroSnAs4+Ejymp3A3En7M3jZQHH0rNHPjj1FxViIAed3rdqGjPJR2l LGmkLJ+7AOwtgnt3K4th31ZDADGPyxheLZa4q9VEIRhqC6VQcxCMFnNoxZOhJHYS4HZD saZ9qfXWIBYnVbhKwNeZWeuvWDlKI6S2g2ugMxzfdWTXR0jgMvsjuPdzb3cibMqufbqt ok0Q==
X-Gm-Message-State: AFeK/H3mev+3a13Ld6KLn4zOVhkfSDjVwyqtZ/uu+VtapM12h7JthOJC/aPVQxnWfV/x5w==
X-Received: by with SMTP id f74mr18457199wmd.109.1489573579053; Wed, 15 Mar 2017 03:26:19 -0700 (PDT)
Received: from ?IPv6:2620:f:8000:210:ad06:e502:4ef7:7c7e? ([2620:f:8000:210:ad06:e502:4ef7:7c7e]) by with ESMTPSA id 136sm18897396wmg.12.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 03:26:17 -0700 (PDT)
From: Roy Arends <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 15 Mar 2017 11:26:16 +0100
References: <> <> <> <> <> <> <> <>
To: dnsop <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Mar 2017 10:26:22 -0000

Dear Paul (and wg)

I apologise for the tone. This went south quick and was due to my confrontational style of writing. The secspider-stats are indeed a good indicator, and convinced me that we shouldn’t make SHA1 related DNSKEY algorithms a "MUST NOT”.

In the spirit of being constructive, we (Jakob Schlyter, Matt Larson and I) have written a small draft (draft-arends-dnsop-dnssec-algorithm-update) that does two things:

it changes RSASHA1 from “Must Implement” to “Recommended to Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
it changes RSASHA256 from “Recommended to Implement” to “Must Implement”. 

The main motivator for this is that implementors have an incentive to move their implementations “default use” away from RSASHA1 (for instance, when a user generates a DNSKEY without specifying an algorithm, or when choosing an algorithm for signing in the presence of more than one algorithm.

This is done in the style of RFC6944, which states that anything that updates the registry table must obsolete RFC6944 (not just update). Therefor, it is as minimal as possible, with no guidelines and no recommendations for the future.

This is NOT a competing draft, though the titles look alike, and I do like to see advice and guidelines for developers and operators in a draft on the BCP track, not proposed standard.

I’m looking forward to discuss this with the working group on the list and during the Chicago IETF DNSOP session.


Sometimes Grumpy.
(Roy Arends)