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

Phillip Hallam-Baker <hallam@gmail.com> Tue, 17 May 2011 16:07 UTC

Return-Path: <hallam@gmail.com>
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 C5D8AE0834 for <dnsext@ietfa.amsl.com>; Tue, 17 May 2011 09:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 2HceRzBawlqj for <dnsext@ietfa.amsl.com>; Tue, 17 May 2011 09:07:22 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7F14E06C8 for <dnsext@ietf.org>; Tue, 17 May 2011 09:07:22 -0700 (PDT)
Received: by gxk19 with SMTP id 19so258216gxk.31 for <dnsext@ietf.org>; Tue, 17 May 2011 09:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OPOmumHdxojHG/uBlx89YS+FfXcoCAPb8IjFM+V5glU=; b=OrKTcLNTbxgaYoisxRSAZ7TejiLW+WVGd3B90ZSs3ltVZbRtDDTMH1XB2yALccauB5 vxlMxHIRCVAsymcpYGp5lS5eRo932gAa8FN/zAUdpdbGWUxOyGGBcl5u5xthldp52WPa PhHEpb/9d3DYwVD5OziLzZq8W8g0EsYSUCiFw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EY64rfM0A8BtuAZyAS/dBiIvvRWuPuL9NZFWnLC7E+rNRaCIDDLkKas9nBrLR6DQTE Gk49W25kHMtrWwNn7eXvLYhO5iyu75w6+KyDILZ/4IuEcCSIK7kfGXKmgbx1VOy5wJrq eVwm8V/IE1iwgy0KhsKO6ULDam7aG2pA0jBE4=
MIME-Version: 1.0
Received: by 10.101.2.1 with SMTP id e1mr439054ani.18.1305648441909; Tue, 17 May 2011 09:07:21 -0700 (PDT)
Received: by 10.101.36.13 with HTTP; Tue, 17 May 2011 09:07:21 -0700 (PDT)
In-Reply-To: <BANLkTikTiEwLWP10FoqO5wHrVK31RGHR8A@mail.gmail.com>
References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> <BANLkTikTiEwLWP10FoqO5wHrVK31RGHR8A@mail.gmail.com>
Date: Tue, 17 May 2011 12:07:21 -0400
Message-ID: <BANLkTi=rkYRodQtW3tWg=W6oB6HQsM9+RQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: multipart/alternative; boundary=001636c594ff94e2eb04a37af719
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsext@ietf.org
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: Tue, 17 May 2011 16:07:23 -0000

Some points responding to various issues in the thread.

1) No, it is not likely that we will have an issue with SHA-1 with respect
to DNSSEC. The reason for this is that DNSSEC is not used to provide
non-repudiation. Thus it is not necessary to be able to state today that we
are confident that SHA-1 will be acceptably secure in 20 years time.

I have asked Adi Shamir about likely progress on SHA1 and I think we are
good wrt DNSSEC for at least ten years.


2) Despite this, there is a cost to using non-standard or deprecated crypto.
Every single time someone wants to use a deprecated algorithm they have to
produce a justification for doing so. Those costs mount up and the point is
soon reached where the cost of constantly explaining why SHA-1 is safe is
greater than the switching cost.

I regret not proposing to upgrade DIGEST to SHA1 when we had the chance.
Even though it would not add any security to the scheme (any attack on the
digest construction is dominated by brute forcing the password space), it
would have saved time overall.


3) There are real benefits to making exactly one set of cryptographic
algorithms mandatory across all IETF protocols. At this point we don't have
much discussion over whether to make RSA or AES mandatory they are just the
default mandatory algorithms to be used across the board. I expect that the
SHA3 competition will result in a similar situation for Digest and MAC
functions.

That will still leave some niche requirements for RC4 and DSA and once all
the patents are expired there will be a likelihood of adding ECC. But as far
as mandatory to implement is concerned, I think we can limit the set to
RSA2048 + AES + SHA3 + SHA3-MAC.


4) Since SHA3 is being worked on right now, it would seem to me that the
appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip
straight from SHA1 to SHA3.


5) Since RSA1024 is in the process of being deprecated, DNSSEC may well turn
out to be one of the cases where there is an exception to requiring RSA2048.
DSA-SHA3 will be slower than RSA but the signatures created will be 512 bits
as opposed to 2048 and that is likely to make a difference for DNSSEC.


6) If we end up adding a mandatory algorithm we might well want to revisit
some of the other design considerations in DNSSEC. At the time Don made his
original proposals there were several optimizations that could have been
employed that were in patent. Now those patents are expired it may make
sense to re-open them.

One of the biggest hassles in DNSSEC is that the RRSIG records cover
individual record sets of the same type rather than all the records at a
domain. This is a fairly obvious candidate for using Merkle trees. So there
would be one public key signature for all the records in the zone and each
individual RRset would contain the intermediate tree nodes to enable it to
be verified.

The way I would do it would be to define a new Signature algorithm for
DSA+SHA3+Merkle Trees.




So my conclusion is that the group should take no action on SHA1 now but
that it should return to work on this topic after the SHA3 competition is
completed and it should consider a proposal that could start deployment long
before it became essential to make a switch.