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

Phillip Hallam-Baker <hallam@gmail.com> Tue, 17 May 2011 20:43 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 D4C5CE0781 for <dnsext@ietfa.amsl.com>; Tue, 17 May 2011 13:43:18 -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 MjPFukf1xG66 for <dnsext@ietfa.amsl.com>; Tue, 17 May 2011 13:43:17 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57976E06DB for <dnsext@ietf.org>; Tue, 17 May 2011 13:43:17 -0700 (PDT)
Received: by gwb20 with SMTP id 20so373653gwb.31 for <dnsext@ietf.org>; Tue, 17 May 2011 13:43:16 -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=8YYtLtuaxjZxjfrpwMxi2xazu5tfHd8uTHareLf+C8A=; b=dtpLDoAFFEqA6uDVdUS/YXTPPmtWDm9RCQrw89AYazaWoxbxdLZz0fSU/0GgWEvjbY oV80K+RvtJDYu++kAmC2wJ4lyX6+GX002QnrLnRzcbN0EfzUOvVKTkUmWRNvBHyHHzBI 6Zg5I3+gJq3ckv9YFkgew+4qeIJ3FEdOR6V6w=
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=ak8Ki3hH7tKL7pnzBejbs1S7SO82xv3OEfjx9HLImpX3L/pm0822Kb5fjed4gKsCqt 63MhGGeKPzcK2EVINEgMNsQ2lvKvqP0YvFjybgTN/TnKCEx7Qmnsnxn21NHAp2D5K1IA Vj1OX3tsnS/SSOuqf+LOMasCmoO8QdkOIKVGA=
MIME-Version: 1.0
Received: by 10.101.98.8 with SMTP id a8mr623591anm.62.1305664996646; Tue, 17 May 2011 13:43:16 -0700 (PDT)
Received: by 10.101.36.13 with HTTP; Tue, 17 May 2011 13:43:16 -0700 (PDT)
In-Reply-To: <alpine.LSU.2.00.1105171833440.19348@hermes-2.csi.cam.ac.uk>
References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> <BANLkTikTiEwLWP10FoqO5wHrVK31RGHR8A@mail.gmail.com> <BANLkTi=rkYRodQtW3tWg=W6oB6HQsM9+RQ@mail.gmail.com> <alpine.LSU.2.00.1105171833440.19348@hermes-2.csi.cam.ac.uk>
Date: Tue, 17 May 2011 16:43:16 -0400
Message-ID: <BANLkTimpMaWuudhoRV4hyrCGmU1jjoZtPg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tony Finch <dot@dotat.at>
Content-Type: multipart/alternative; boundary=001636ed6ce3521f8504a37ed29b
Cc: dnsext@ietf.org, Paul Hoffman <paul.hoffman@vpnc.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 20:43:19 -0000

On Tue, May 17, 2011 at 1:38 PM, Tony Finch <dot@dotat.at> wrote:

> Phillip Hallam-Baker <hallam@gmail.com> wrote:
> >
> > 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.
>
> A useful point, thanks.
>
> > 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.
>
> SHA2 is already widely deployed in DNSSEC, e.g. in the root zone and
> many TLDs.
>
> > 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.
>
> Why is that a hassle? It seems like an advantage to me. In particular it
> makes it possible to sign a dynamic zone where there is no such thing as
> "all the records at a domain".
>

It means that a client will frequently need to verify multiple RRSigs for
the same zone.

Using Merkle trees the public key operation can be done one per zone and
leveraged over all the records.


For example, let us say that example.com has A, AAAA, TXT and MX present.

The signature is calculated as follows


<sig>  = DSA ( H (  H ( H(A) + H (AAAA)) + H ( H(TXT) + H (MX) ) ))

The RRSIG records would be

A:  SIG + [H (AAAA)]  + [H ( H(TXT) + H (MX) )] + '0'
AAAA: SIG + [H (A)]  + [H ( H(TXT) + H (MX) )] + '1'
TXT: SIG + [H ( H(A) + H (AAAA))] + [H (MX] + '2'
MX:  SIG + [H ( H(A) + H (AAAA)) ] + [H (TXT)] + '3'

Note that each RRSIG is 512 + 256 + 256 + 16 = 1040  bits/130  bytes long
plus  whatever packaging is needed.

When validating this type of RRSIG the validator would first check to see if
it already has a signature verification result cached for the SIG value. So
even if there were 4 RR types in a zone it would only perform one public key
operation.


-- 
Website: http://hallambaker.com/