Re: [DNSOP] Current DNSOP thread and why 1024 bits

Colm MacCárthaigh <colm@allcosts.net> Wed, 02 April 2014 15:26 UTC

Return-Path: <colm@allcosts.net>
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 3F7AE1A0299 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 08:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 gBamkaJLoRtw for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 08:26:39 -0700 (PDT)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C36201A0297 for <dnsop@ietf.org>; Wed, 2 Apr 2014 08:26:39 -0700 (PDT)
Received: by mail-ob0-f182.google.com with SMTP id uz6so422887obc.41 for <dnsop@ietf.org>; Wed, 02 Apr 2014 08:26:35 -0700 (PDT)
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=vZPzBdyXVt4NEc0w3JvCYslpOj/svp12F7iUEOezfzw=; b=W786RtAOmF+29RhFi3+2LPUkWrjbd5mjMvFRdg9V2BqIALjQuSuZgzPCqghiq8Akh9 upainFtN+WgWcL/T70Yr0Xjr9IzBtapZbyu3f6qrGM/gz8aTuImxz09cwcZfNFHgzH0Z dYGK/zNH7wU5sNbyt1mUDWIUPzO/l/cmbW97MGRtHGbclkJk7xoLGUcwoCc9NxdeMacL w3jghjHxhhtFDomUi+y4Rbw/lMSznJFphqXfH3bH+NQFtSL13Uzh00s+n0ZKF5GMBrKR bfMulC0bckhmrfT2eeVWYlQpb+Nz66Zw9jLasJUAHGjcsqXryNKZ9BgWtRETAzjiW54q cG6A==
X-Gm-Message-State: ALoCoQnyZvqf7VUYvVgBeHPN8kGzcpBgnPPR5qDffmZ8CzpVGtHd5jXgnECnlrxtjzyQ4iL17w9N
MIME-Version: 1.0
X-Received: by 10.60.125.195 with SMTP id ms3mr575628oeb.3.1396452395539; Wed, 02 Apr 2014 08:26:35 -0700 (PDT)
Received: by 10.76.20.164 with HTTP; Wed, 2 Apr 2014 08:26:35 -0700 (PDT)
In-Reply-To: <1904697C-49EF-4F77-A71A-3E0E4FC16575@cox.net>
References: <0EA28BE8-E872-46BA-85FD-7333A1E13172@icsi.berkeley.edu> <53345C77.8040603@uni-due.de> <B7893984-2FAD-472D-9A4E-766A5C212132@pch.net> <102C13BE-E45E-437A-A592-FA373FF5C8F0@ogud.com> <474B0834-C16B-4843-AA0A-FC2A2085FEFB@icsi.berkeley.edu> <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com> <1904697C-49EF-4F77-A71A-3E0E4FC16575@cox.net>
Date: Wed, 2 Apr 2014 08:26:35 -0700
Message-ID: <CAAF6GDcGRyf_J+HJ2MP1Hso==iAS-a4prOpAZ7U-A8V1uiL=ew@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: Edward Lewis <edlewis.subscriber@cox.net>
Content-Type: multipart/alternative; boundary=047d7b33cf28fb8f3d04f610e806
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/06Lv5gzxaEME2qVx9Dg0a-Te-H0
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Current DNSOP thread and why 1024 bits
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, 02 Apr 2014 15:26:44 -0000

On Wed, Apr 2, 2014 at 6:30 AM, Edward Lewis <edlewis.subscriber@cox.net>wrote;wrote:

> I found that there are two primary reasons why 1024 bits is used in zone
> signing keys.
>
>  One - peer pressure.  Most other operators start out with 1024 bits.  I
> know of some cases where operators wanted to choose other sizes but were
> told to "follow the flock."
>
> Two - it works.  No one has ever demonstrated a failure of a 1024 bit key
> to provide as-expected protection.
>

Cryptographic failures are often undemonstrated for decades. If a state
actor has broken 1024b keys, they're unlikely to advertise that, just use
it now and then as quietly as they can.

Secondly, the application of signatures in DNS and the nature of the DNS
protocol itself presents significant risks that don't make a
straightforward comparison easy.

Suppose your goal is to intercept traffic, and you'd like to cause
www.example.com, a signed domain, to resolve to an IP address that you
control.  Now suppose you also happen to have a /16, not unreasonable for a
large actor - small even. If you can craft a matching signature for
www.example.com with even one of your 2^16 IP addresses, you've succeeded.
You don't have to care which particular IP address you happened to craft a
matching signature for.  This property makes it easier to sieve for
matching signatures.

>From these two main reasons (and you'll notice nothing about cryptographic
> strength in there) a third very import influence must be understood - the
> tools operators use more or less nudge operators to the 1024 bit size.
>  Perhaps via the default settings or perhaps in the tutorials and
> documentation that is read.
>

Do you think that this would be as relevant to the root zone and large TLDs
though?

-- 
Colm