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

George Michaelson <ggm@algebras.org> Wed, 15 January 2014 01:48 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 409831AE16A for <dnsop@ietfa.amsl.com>; Tue, 14 Jan 2014 17:48:08 -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 FHa1kdja8SOu for <dnsop@ietfa.amsl.com>; Tue, 14 Jan 2014 17:48:06 -0800 (PST)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3E1AE150 for <dnsop@ietf.org>; Tue, 14 Jan 2014 17:48:06 -0800 (PST)
Received: by mail-pd0-f181.google.com with SMTP id p10so432212pdj.12 for <dnsop@ietf.org>; Tue, 14 Jan 2014 17:47:55 -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=87ngRWFQyABc7U/Pz4H5pfv4Ny2KyGjoLFYGlRraFDc=; b=MZCzP/VZgS2+TwY2E/l/P+rLKeyYaQ0m9OoT73Hlf8En00LWvX29RHnANJ85o8Mk5t xPFuq5KqV+b8WbNUuRbeJxVJ7wk86itH7WkvrwumYuMmEJ+/lkTq1o9yuKBUCyLoTCjc 4jc2vAQZJw9VVSa+Mn/LNEn2SV4/prf6duIsEW0g8LBiZzd0/0H0hBjWzNK1t1l0O2wd +pBNoXzveLnhXdFVrd+w1Afyxi1esuzaLpnShXG6dJ0aaR5uOnCoYkbk7N2eQNNDwmZf NgI8Kc5Nsp+pPBHVm8HeoeiRzaQGpVZDj/g5iRqiO1adpkXfUeT1qtisJGPNfMSFAc9+ WM1Q==
X-Gm-Message-State: ALoCoQnE9iHLFa/x38zwnYxGnf6pfpQj2eVOan7HZy59p6HP5wNPiXIMbNhsBgGhpezqloby238Y
MIME-Version: 1.0
X-Received: by 10.66.142.107 with SMTP id rv11mr5382377pab.17.1389750475353; Tue, 14 Jan 2014 17:47:55 -0800 (PST)
Received: by 10.70.89.41 with HTTP; Tue, 14 Jan 2014 17:47:55 -0800 (PST)
X-Originating-IP: [2001:dc0:a000:4:f02e:a876:58e:91ba]
In-Reply-To: <ACC19E1E-1D30-4A8A-B128-67FBF700EBDE@vpnc.org>
References: <20140114172240.GO17198@mx1.yitter.info> <C6EFA413-1FFC-4188-B98A-13C747981FBC@hopcount.ca> <20140114200849.GA17907@mx1.yitter.info> <CAKr6gn0rQa8CeA+5tBYnr2G52-P-qd4V1g=ohQMwgi9osfQYvQ@mail.gmail.com> <ACC19E1E-1D30-4A8A-B128-67FBF700EBDE@vpnc.org>
Date: Wed, 15 Jan 2014 11:47:55 +1000
Message-ID: <CAKr6gn2s+qdH0HDMZMH=xpJ-m-BWLO6M4exUp-EJ5_CKSXdruw@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a11331e466905d104eff87fa8
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: Wed, 15 Jan 2014 01:48:08 -0000

thanks for the cluestick hit. so we can't trade multiple sigs for length,
which means for public benefit reasons adding more visible signers at the
top does irredeemably increase the dataset size because the key size has to
stay high.

there are no free lunches for public accountability.


On Wed, Jan 15, 2014 at 10:16 AM, Paul Hoffman <paul.hoffman@vpnc.org>wrote;wrote:

> On Jan 14, 2014, at 3:04 PM, George Michaelson <ggm@algebras.org> wrote:
>
> > 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
>
> I am not a cryptographer but I *do* play one on television, and that
> proposal is terrible. Breaking asymmetric keys gets logarithmically harder
> as the key size goes up; that's why no one has publicly broken a 1024-bit
> RSA key, even though they have had much, much more time (and now-faster
> CPUs) than the earlier breaks.
>
> It would orders of magnitude easier to break 4 512-bit keys than one
> 2048-bit key. The work would also parallelize better so that you need
> smaller systems to do the work.
>
> --Paul Hoffman