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

Paul Wouters <paul@nohats.ca> Wed, 01 March 2017 01:57 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 674B81293FD for <dnsop@ietfa.amsl.com>; Tue, 28 Feb 2017 17:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 EE5w3E_r2v9J for <dnsop@ietfa.amsl.com>; Tue, 28 Feb 2017 17:56:58 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 6EB8D1289C4 for <dnsop@ietf.org>; Tue, 28 Feb 2017 17:56:58 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXz8Q08t8z3xJ; Wed, 1 Mar 2017 02:56:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488333414; bh=OnJbpuZpuOAZvkkdECWeOEMLrkugAJMXCYXibaoH6ng=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B31ELZjUB65MmNgRCoXs4A0yUu7jm0kSBcTwB67XxFyl0W5BLaMBwHD/mqzJ/WuRz pmNbpsotWc3LipQYOBSExPvv+ZcAfVxjQ1GRAFKw4G/deGaYNC+RIFGLh+u4QoA16n 6iB+KGLSs2yGChI7XD2ot0ZjS4werRQMziLIGBNo=
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 jjpMzccbOAkv; Wed, 1 Mar 2017 02:56:50 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Mar 2017 02:56:50 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0E65336A2; Tue, 28 Feb 2017 20:56:48 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0E65336A2
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ED4A8418A26F; Tue, 28 Feb 2017 20:56:48 -0500 (EST)
Date: Tue, 28 Feb 2017 20:56:48 -0500
From: Paul Wouters <paul@nohats.ca>
To: Roy Arends <roy@dnss.ec>
In-Reply-To: <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec>
Message-ID: <alpine.LRH.2.20.1702282052220.28866@bofh.nohats.ca>
References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> <F40B69DF-6391-4008-A7CD-C85277952D8A@dnss.ec> <alpine.LRH.2.20.1702281627360.22841@bofh.nohats.ca> <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1zP7ZA_xapYbXHmvmiTCdcTSd6M>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 01 Mar 2017 01:57:00 -0000

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.

>>> 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?

>> 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.

>> 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?

Migration should be done responsibly.

Paul