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

Roy Arends <roy@dnss.ec> Thu, 02 March 2017 11:00 UTC

Return-Path: <roy@dnss.ec>
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 19D8D1297BE for <dnsop@ietfa.amsl.com>; Thu, 2 Mar 2017 03:00:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
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 SrjECE5eQu_K for <dnsop@ietfa.amsl.com>; Thu, 2 Mar 2017 03:00:09 -0800 (PST)
Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E6A1297CB for <dnsop@ietf.org>; Thu, 2 Mar 2017 03:00:08 -0800 (PST)
Received: by mail-qk0-x244.google.com with SMTP id n127so17799816qkf.2 for <dnsop@ietf.org>; Thu, 02 Mar 2017 03:00:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ChI6LviXn2RfAxSPqNZsIGHTyFYRvHfFOiyZx2DJ4Tw=; b=Zu+/c8yMH4NlHrj/5kTIyLUhUPqAydx8WwXuZ+K59KQUoSx0syiYMw/GODMi8S7eN3 MvkJNCZ/qQxof0hZvo14Vp3TpXH0Fj1JiCzKvbNhyR3vbzu2QNbQYfLz+pa6HWe1U1aX JANbr6M2QRiXGGY2mcFpIDpXALOFqsW0pXvd4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ChI6LviXn2RfAxSPqNZsIGHTyFYRvHfFOiyZx2DJ4Tw=; b=N4amzl60brndAK5/yi+Gndr+x+pHfCWIRiupTrJu8hP72HYRV1NYHta78gin0Otmza e0t52mseVNfT1OzDtUh5d9ORLNfFG9xE3VQVhIRP6cpoIJZgTYE93O/qeoYFoUY0Zdtt +Z/k4cvOahfvyx7a0pS2ZgL0C22EgB1bBnzoL3kD5ZSvx9oIKD0r9tFwT5lvJbLFGI0c 8UFbAWJb/RHpUWyjWUH/sQtOMhOL5g+EB98wqokhcaO5EURx8vo4ynHTgDi0xNAu4lUY 9Bz4nr6xetVM7MLJfHUc+J7w1J5ujVVTe0qw4Xb3UFVPk8XgnrGZLxR2m2BMqlrakRcy IrOg==
X-Gm-Message-State: AMke39lmflQoe9o5ooCHtBghpMECq3e9dCDfcyxRbp3SH+5QF2yNxwibOfZGaht4RT8mJw==
X-Received: by 10.55.73.201 with SMTP id w192mr16080296qka.7.1488452407395; Thu, 02 Mar 2017 03:00:07 -0800 (PST)
Received: from [192.168.1.82] (host217-42-115-130.range217-42.btcentralplus.com. [217.42.115.130]) by smtp.gmail.com with ESMTPSA id o16sm5075114qkl.67.2017.03.02.03.00.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 03:00:06 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <alpine.LRH.2.20.1703011221400.15273@bofh.nohats.ca>
Date: Thu, 2 Mar 2017 11:00:03 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <76B12F6D-9D53-4FEB-974D-BB4D6DB02F0B@dnss.ec>
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> <alpine.LRH.2.20.1703011221400.15273@bofh.nohats.ca>
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rx0CqTLU130qilTCnaPZUjrLhgU>
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: Thu, 02 Mar 2017 11:00:11 -0000

> On 1 Mar 2017, at 17:41, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Wed, 1 Mar 2017, Roy Arends wrote:
> 
>> 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.

This is not true. The shattered.io pdf files contain an embedded jpeg. The difference between the files is in the jpeg comment. The size of the difference is 128 bytes. These are two consecutive 64 byte inputs. The two versions hash to the same output, given the prefix.
The prefix is 192 bytes, and contains the PDF header and the start of the embedded JPEG. This could have been any arbitrary content (such as owner name, TTL, class, type, etc) as long as it is a multiple of 64 bytes (size of input block for sha1).

These 128 bytes can be the content of the DNSKEY. It would therefor not have to be “intersparsed with mandatory DNS markers”.

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

Implementer should follow spec. Spec sez MUST or SHOULD. 

Now it says MUST- MUST+ MUST SHOULD- SHOULD+ and SHOULD. Very confusing. Which one should be implemented? How do I add a grade of importance to specific algorithms, while the protocol itself doesn’t care. DNSSEC has no signalling which algorithm is more or less important in the future. 

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

Okay, so you did make it up.

1/3 is not 1/2. How many of those SHA1 keys are used in conjunction with non-SHA1? That is, how many would still be secure when SHA1 is ignored?

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

This is nonsense.

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

Again, how many zones does it affect when most of them have SHA2 as well? 

The damage I’m trying to avoid is the false sense of security you are inflicting by not taking the proper action.

It is because the lack of action from specs like these that BIND-9.11.0 still ships with SHA1 defaults:

$dnssec-keygen
Version: 9.11.0
Options:
    -a <algorithm>:
<snip>
       (default: RSASHA1, or NSEC3RSASHA1 if using -3)

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

oh dear.

I see that further discussion is useless. 

Roy