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

Roy Arends <> Wed, 01 March 2017 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50BE5129449 for <>; Wed, 1 Mar 2017 06:30:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] 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 OE0yF96xkwsZ for <>; Wed, 1 Mar 2017 06:30:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE6B512940C for <>; Wed, 1 Mar 2017 06:30:11 -0800 (PST)
Received: by with SMTP id n186so70691962qkb.3 for <>; Wed, 01 Mar 2017 06:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HEVissP7vSUCqiS+iNvy+qHgxlrB6dyuG67ILQqeyYQ=; b=UUjU01Q7JUPi+rdRh7xWtgzY6kpuFl5O3s3HuKDQs/R34G11ON1Zh6OLVqXAEY9Z2r R7m8AbZwO7zk95pIxdxg0F9kmLnEvjnIJHiQ5VtWS6UufmSfSJt2RM6xw29mdu93DDVV qtxVSOdpAxib5LtPXfMJz/lrpsMO5WvJapa3U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HEVissP7vSUCqiS+iNvy+qHgxlrB6dyuG67ILQqeyYQ=; b=G2nagK3jUcoWZ5iihvjEYEOs750RWmdcBlM4SXr6c61qoS2Wezjrp76Qh4J4mphecm A5/LohCbvg4bcgt0l0EiPKw2M54c3F0+jn4pr1txVT3Om82lsivUw6HIGTjQdspmlV5U ZkNWsm4XHAEncFlT4+SsueJzNVONAjZcszEv6qvWg4MOYY0t0sCt7Vd5gND3IfxRxcqz X0jBGZkzUA9arkETSKQsriPRphiYX+o7MyDI3sy2uXVvbRJmcaM2opHOxWsmi//Dz8+3 IwZ/gy0Y6gHWB9a82t+BoodglzvGUlOOuAamFRhwmc+BDHb6ujGYqmtJ40z2id3ztATW sCGA==
X-Gm-Message-State: AMke39n4g+78k+U3OuL3pfNhGZOYVqE68XP2XckQQ6SBcttAWVMsvoO+WezexPDRrzGT/g==
X-Received: by with SMTP id u18mr10801892qtc.51.1488378610350; Wed, 01 Mar 2017 06:30:10 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d30sm3256882qtb.18.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 06:30:08 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Roy Arends <>
In-Reply-To: <>
Date: Wed, 01 Mar 2017 14:30:06 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: dnsop <>
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.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Mar 2017 14:30:13 -0000

> On 1 Mar 2017, at 01:56, Paul Wouters <> wrote:
> On Tue, 28 Feb 2017, Roy Arends wrote:
>>> We can't stuff PDF prefixes into this,
>> We don’t need to.
>>> there are a lot less bytes
>>> for an attacker to play with.
>> A CNAME chain will give you plenty of bytes to futz with.
> None of the SHA1 hases we use are covering a chain of records.

The point is not the chain itself, but the right hand side of the first CNAME in a chain. Make it long enough and you’ll have enough bits.

An attacker needs two successive 512 bit blocks and a prefix. 

However, you _do_ hash a chain of records. Forget CNAME, take a DNSKEY RRset with a few DNSKEY records in it. A fake 1024 bit key aligned just right will do the trick. 

All in all. The assumption that there are a lot less bytes for an attacker to play with is incorrect. 

>>>> Please also refrain from using MUST- SHOULD+ and SHOULD-.
>>> For this SHA1 case or in general?
>> In general.
> I disagree then. Did you read the motivation of why we use
> those terms to clarify that we expect an algorithm to be
> promoted or demoted in a future update?

Yes. I've read it. It is silly.

I expect any algorithm to be demoted in a future update. 
I expect any algorithm to be promoted in a future update.
I expect world peace too. And a pony!

I understand that you want to reflect, at the time of writing, the expectation that in the future some algorithms are king, some algorithms were king and some algorithms will be king. 

However, the only thing you _can_ state is what you know at the time of writing: some algorithms are king, SHA1 algorithms were king. Anything else is guesswork.

Why don’t you leave these future predictions to a future update.

>>> I'd say we could update the DNSSEC
>>> Signing entry from MUST- to SHOULD NOT
>> Good. That is exactly my request.
> This is still only meaningful if the signer software vendors
> in general agree with this. If they will just ignore this
> document, then I feel there isn't much point in proceeding
> with it.

Vendors are on this list and usually fairly vocal. I welcome their input. 

>>> but I would leave SHA1 for
>>> DNSSEC validation at MUST-.
>> I’d say you have to update that as well to SHOULD NOT.
> That is just unreasonable. Do you want half the the DNSSEC
> signed zones in the world to go insecure or bogus?

I have different numbers, but I do prefer a zone going bogus rather than falsely secure. 

Can you please show where you got the “half the the DNSSEC signed zones in the world to go insecure or bogus” numbers, or are you just picking a convenient number to make your argument?

> Migration should be done responsibly.

Sure. But a migration doc is something else. This is not it.