Re: [dnsext] DNSSEC, robustness, and several DS records

"W.C.A. Wijngaards" <wouter@NLnetLabs.nl> Thu, 12 May 2011 08:20 UTC

Return-Path: <wouter@nlnetlabs.nl>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4255FE070C for <dnsext@ietfa.amsl.com>; Thu, 12 May 2011 01:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXyLzl9oUnAf for <dnsext@ietfa.amsl.com>; Thu, 12 May 2011 01:20:44 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EE7E0734 for <dnsext@ietf.org>; Thu, 12 May 2011 01:20:40 -0700 (PDT)
Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p4C8KbW7004034 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsext@ietf.org>; Thu, 12 May 2011 10:20:37 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl)
Message-ID: <4DCB9855.7020805@nlnetlabs.nl>
Date: Thu, 12 May 2011 10:20:37 +0200
From: "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: dnsext@ietf.org
References: <201105112250.p4BMoQZk020211@givry.fdupont.fr> <4DCB2E3F.4030701@dougbarton.us> <20110512015806.209E0EAF182@drugs.dv.isc.org> <4DCB4421.5020306@dougbarton.us> <1305174244.2793.8.camel@localhost> <20110512075546.GA17883@nic.fr>
In-Reply-To: <20110512075546.GA17883@nic.fr>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 May 2011 10:20:38 +0200 (CEST)
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 08:20:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stephane,

On 05/12/2011 09:55 AM, Stephane Bortzmeyer wrote:
> Can you explain how such an attack could be possible? Since the DS
> record set is signed, modifying the SHA-256 record to make it invalid
> (so the bad guy can attack SHA-1 with clever cryptanalysis) is not
> possible (unless the bad guy can attack the provisioning channel and,
> in this case, you're toasted, whatever the RFC says).
> 
> [Doug Barton already made more or less the same argument, if I
> understand him correctly.]

The weakness in MD5 that I heard about (on slashdot I think) was that
you could construct data that matched a particular hash.  So, if the DS
contains some particular hash, then you produce a DNSKEY-dataset whose
hash matches the hash given.  And spoof the DNSKEY (not the DS).

However, even for MD5, the weakness that I once heard about needed a lot
of data (one megabyte? wasn't the example a postscript document?), which
would be hard to fit into a DNSKEY record in a way that you can still
use the DNSKEY to sign data.  Of course, you might want to get better
advice, such as from the authors of RFC 4509.  And they tell you to
ignore the SHA1 if a SHA2 is present.  with SHOULD (so, this is the best
thing to do, but there could be some exception, maybe for diagnostics or
so).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNy5hUAAoJEJ9vHC1+BF+NjsQP/3xpOpuwsf4HFNALvf9qRJUv
/ofHIXmfD6EjY1psvEaxHrkp5vEIKoTGi3PlYFMEpAvAOiZsE6+M3GZN+ryvXNdY
bS7eM6SFRCNz/I0oTtNhVluAB/dilk/Eh/zUPhoGc7Osz7HrWkl3JzWThkYAU3yS
I9JmxqL76xKdl+vSqwuf+V43Ar6nqono8HzLzHVLvLpDYGMtPcQkv+E92FiDVoHD
8+TIBrHfla8finLF39Xb9VyQRtw6rPgGri9GwYW4rZDhB3nGyKoFhGBxHbzUHEiN
m4bOfzaGlH3M9opajYQjDlaJTTb2qtWV7aiE9+BWP0puJ63IdHV74lkbrLtMKXC1
/48bXL0ynMjZazQzr1byvdwnPCSpxxn3J/hVe/EJUI70geEl2+RFFzgu1oW1vEPY
2lEPIbQvGjBmS+nfSoFO99wbQcRsrIMRV8biqRE0dlFkcxQyRQQ1YZHhUULEHNSM
AnVIfvG1B1GYl9iFOAANde8+spf7boqPnqf7TMbLmmrffAtItb6CMDMhQxTwiO9g
XoEcsOJLLoKikQBkwN73dkagZhPNALaF9hG8mwXwR90Ze0iYXvFLggL11b/iP4VL
XfcfJwMcj5twU52277zy1Zn95clzjLQvY4uAOKcmrNYBaWEpq3S9UDQMzJgn7Ttg
0BRXEW5phfX2DHlK2dVN
=lYfw
-----END PGP SIGNATURE-----