Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

George Michaelson <ggm@algebras.org> Tue, 14 January 2014 23:04 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91461AE22E for <dnsop@ietfa.amsl.com>; Tue, 14 Jan 2014 15:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 607hLnIMbdEg for <dnsop@ietfa.amsl.com>; Tue, 14 Jan 2014 15:04:24 -0800 (PST)
Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7D91ADFF3 for <dnsop@ietf.org>; Tue, 14 Jan 2014 15:04:24 -0800 (PST)
Received: by mail-pd0-f171.google.com with SMTP id x10so283666pdj.2 for <dnsop@ietf.org>; Tue, 14 Jan 2014 15:04:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LSLo2JSTmoA5JFV/Fve70CBYtNwwgWLcNy69wg5AZqk=; b=FfPyE10gby0l3qBs85HTeLk+09r0elotEqw9lW+l1Df07dr6R9hLh6Ok100KmluMqD c7KAGaxqdvZ/T38BJ+k7sVeiz/5+ka+V9KUy0ZO651GkD3d+U+Tt9IuTr8Kd+rTbmr1B cH8u8FcD+Ld4tju36ghZtY7Qv8E+Q5drxQX22EximVl9jG7+/YOC1LU7HPV6qX6UYlSm 9sx2iyty6K9PXA6NMlFRP30n3d7Xsf4z0n0SUslcrWhPwTISvQR3TveJtp+j/zOS1LFb UNYBTk8H3k28+X/7MpSL2K6zizc7Y9ifLHx/5ucwSAgJ6lpg8vagca5KeAV5x46SccFY PmAw==
X-Gm-Message-State: ALoCoQmCc5xaYWXGaU7FH6RJuGZlmOnA79w5XWXIlRh7FEs4+m64ZR7F3k8F99hwbfQJsbbq+FTs
MIME-Version: 1.0
X-Received: by 10.66.27.72 with SMTP id r8mr4743301pag.62.1389740652769; Tue, 14 Jan 2014 15:04:12 -0800 (PST)
Received: by 10.70.89.41 with HTTP; Tue, 14 Jan 2014 15:04:12 -0800 (PST)
X-Originating-IP: [2001:dc0:a000:4:f02e:a876:58e:91ba]
In-Reply-To: <20140114200849.GA17907@mx1.yitter.info>
References: <20140114172240.GO17198@mx1.yitter.info> <C6EFA413-1FFC-4188-B98A-13C747981FBC@hopcount.ca> <20140114200849.GA17907@mx1.yitter.info>
Date: Wed, 15 Jan 2014 09:04:12 +1000
Message-ID: <CAKr6gn0rQa8CeA+5tBYnr2G52-P-qd4V1g=ohQMwgi9osfQYvQ@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary=bcaec52bec1ff0474304eff635d7
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 14 Jan 2014 23:04:26 -0000

If multiple independent entities sign, can't they elect to use shorter
algorithms?

I know 'short can be spoofed' is out there, but since there are now n *
<512> instead of 1 * 2048 is it not theoretically possible that at a cost
of more complexity, it can be demonstrated that as long as 1) the sigs are
all current 2) all the sig agree then the risk of n 512-bit signings is not
necessarily worse than one 2048 or 4096 bit signing, for the specific need
we have: proof of correctness. (n is unstated. 512 is a nonce. I have no
idea what the sweet spot of keysize and number of keys would be.)

therefore, if this is true, trading complexity for keysize might not
increase the initial bootstrap zone transfer size that much.

I am not a cryptographer and do not play one on TV


On Wed, Jan 15, 2014 at 6:08 AM, Andrew Sullivan <ajs@anvilwalrusden.com>wrote;wrote:

> On Tue, Jan 14, 2014 at 01:54:56PM -0500, Joe Abley wrote:
>
> > It's interesting to see that what was actually built in 2009/2010 is
> > largely compatible (at the high-level diagram level) with what was
> > proposed
>
> I thought that was interesting too.
>
> > However, each RKO you add increases the operational risk that an SKR
> > from that RKO might not be obtained within the required window,
> > which puts zone publication in jeopardy.
>
> Good point.  I think the idea is that this is a feature, because it's
> supposed to be the Mutually-Assured Destruction threat that will
> prevent the USG from unilaterally removing some country from the root
> zone (that seems to be the threat people are worried about.  Why is
> left as an exercise for the reader.  Note that I do not promise there
> is a solution to this exercise).
>
> > [If validators took the approach of installing trust anchors from
> > each and every RKO to mitigate this possibility, then they are
> > effectively saying "I'm happy so long as at least one RKO is happy
> > even if all the others are deeply miserable", which doesn't sound
> > like it achieves the document's objectives.]
>
> It _might_, if the idea were instead that validators used n of m.  Ben
> Laurie had a not-completely-dissimilar idea for root TA distribution
> entered in the "rollover" competition back in 2006 or so.  See
> http://tools.ietf.org/html/draft-laurie-dnssec-key-distribution-02.
>
> Thanks for the observations, which I think are quite helpful.
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>