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

Paul Wouters <paul@nohats.ca> Wed, 01 March 2017 17:41 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 69C24129629 for <dnsop@ietfa.amsl.com>; Wed, 1 Mar 2017 09:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 YKzv-aScLuTZ for <dnsop@ietfa.amsl.com>; Wed, 1 Mar 2017 09:41:30 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 6969B1204D9 for <dnsop@ietf.org>; Wed, 1 Mar 2017 09:41:30 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vYN6G1flWz311 for <dnsop@ietf.org>; Wed, 1 Mar 2017 18:41:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488390086; bh=9K+zaPL6gSH/oFhZE36VP8gXmxnK5i7pIZi0TxZ7KdY=; h=Date:From:To:Subject:In-Reply-To:References; b=qv7tBzFA/Kue0b/gcQ+0uORIV7pdNJ3DE146YaxkmfOt5LVhw3PhIbd7AGKEXp4xI wU9W1LdbWlhoA0P8yuj8yjlMP/Hap67exrPIUKZP7ipZjZTkMRT4jbL7HponogWlOo qSPWqeHMu1aEx42M+P/HhCS1WZV5Mu8YQ1rmDMgw=
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 T3no66_1aOma for <dnsop@ietf.org>; Wed, 1 Mar 2017 18:41:23 +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 for <dnsop@ietf.org>; Wed, 1 Mar 2017 18:41:23 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id AB2E23F2851; Wed, 1 Mar 2017 12:41:22 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AB2E23F2851
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9524C41DA420 for <dnsop@ietf.org>; Wed, 1 Mar 2017 12:41:22 -0500 (EST)
Date: Wed, 01 Mar 2017 12:41:22 -0500
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <AC4C0368-1454-4718-95AF-BB4DDECEF17E@dnss.ec>
Message-ID: <alpine.LRH.2.20.1703011221400.15273@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> <alpine.LRH.2.20.1702282052220.28866@bofh.nohats.ca> <AC4C0368-1454-4718-95AF-BB4DDECEF17E@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/x1V3yh_c5q1rtpuqCQ_3E7qwvC8>
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 17:41:32 -0000

On Wed, 1 Mar 2017, Roy Arends wrote:

[cut previously answered items]

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

Still very constrained, 63 octet chunks with a total of 253 octets.

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

Those are still intersparsed with mandatory DNS markers, unlike the
variable size giant blob inside a PDF.

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

Because having multiple MUST or SHOULD entries does not help the
implementer knowing which ones are more important for the future,
and which ones are more there for legacy deployment reasons.

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

Agreed.

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

Well, secspider is pretty good?  http://secspider.verisignlabs.com/stats.html

1,641,133 	Production DNSSEC-enabled zones

RSASHA1-NSEC3-SHA1	1,320,540
RSA/MD5			21
RSA/SHA-1 [RSASHA1]	123,575
RSA/SHA256 [RSASHA256]	2,332,855

Number of keys does not directly map to number of zones (we have 3.6M
keys and 1.6M zones) but this shows 1/3 of the keys are still using
SHA1.

To compare, browsers generally are unwilling to kill something if it
affects more then 0.01% of browsers.

Clearly the goal of our draft is moving this in the right direction,
but saying you want to change the security of a third of the zones
to make a point about SHA1 does more damage than good. And the minus
symbols you so dislike is our way or signaling to people to take
note that something we must support today, is being moved to the
chopping block.

>> Migration should be done responsibly.
>
> Sure. But a migration doc is something else. This is not it.

It is part of it. Whatever is no longer mandatory to implement is given a
death sentence. The whole point of this document, as we did with 7321 and
4307 in IPsec, is to make things orderly but firmly. Walk, not run. Which
is why we made the distinction between validators and signers. And we
really need the help of the signers to gradually stop signing with the
insecure algorithms while giving them a chance to warn their users,
and more importantly, warn the owners of automated shell scripts.

Paul