Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

Phillip Hallam-Baker <> Fri, 28 March 2014 15:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E702F1A065A for <>; Fri, 28 Mar 2014 08:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ZlakSd4IrQC for <>; Fri, 28 Mar 2014 08:42:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::234]) by (Postfix) with ESMTP id D0B4E1A0651 for <>; Fri, 28 Mar 2014 08:42:00 -0700 (PDT)
Received: by with SMTP id ec20so3797297lab.39 for <>; Fri, 28 Mar 2014 08:41:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zC583cB52uL58L7Wn792mlw4FCOh2iQu09SaZSeYh9w=; b=Y05fB9HPVCpv3sLBSRnWtUcz7KEptA0nGAcwZdJ0M+EGMOPeVYCIbl5qbArd1RjhJq 9lCY/NZcFFqwi+8bhVBjaggSubJl7um7DVZKAZpOW7SUewM5/oHIpbuE09pMf7pzTMZF sFHymEaSd1TVJ3IPwRhkMJhuGCrTTjX/hq1UFm7z4+HuqDZ/By/pp7wsX5wYDC4C1By6 Q2wLP8GmT0EdhuCkOGkJJRpqaNUo35jG7jBbPUs0aJggWAsrL+Ej1itkEr3rlAHZu6/T XxO+TIfcMaWuVBIuWs069+s/3vpO1+ADFP9kxTmu1MXv5FtTGFXxUSQqhExNAO0xU9j6 g4yA==
MIME-Version: 1.0
X-Received: by with SMTP id es2mr6156622lac.22.1396021317960; Fri, 28 Mar 2014 08:41:57 -0700 (PDT)
Received: by with HTTP; Fri, 28 Mar 2014 08:41:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 28 Mar 2014 11:41:57 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Thierry Moreau <>
Content-Type: multipart/alternative; boundary=001a1135e20cc18a6104f5ac8a2e
Cc: dnsop WG <>, Nicholas Weaver <>
Subject: Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Mar 2014 15:42:04 -0000

On Fri, Mar 28, 2014 at 11:28 AM, Thierry Moreau <> wrote:

> On 03/27/14 13:56, Nicholas Weaver wrote:
>> So why the hell do the real operators of DNSSEC that matters, notably com
>> and ., use 1024b RSA keys?
>> And don't give me that key-roll BS: Give me an out of date key for . and
>> a MitM position, and I can basically create a false world for many
>> DNSSEC-validating devices by also providing bogus time data with a MitM on
>> NTP...
> [Did not read all the discussion.]
> Suppose I agree with the rationales for keys larger than 1024. Under some
> relatively paranoid assumptions in the threat model, they make sense.
> Turning to the solution space, why not 1280 or 1459? Then increase by ever
> smaller jumps every two years.
> Is it possible that the whole IT security community is social-engineered
> into thinking that anything below 2048 is inadequate for any purpose.
> Because the larger the RSA key size recommendations, the less severe the
> relative ECC performance cost on digital signature verification operations.
> Thus the ECC promoters have an in interest in the underlying expert
> community wisdom.

No, its due to the math.

1024 bit is roughly an 80 bit work factor
2048 is roughly 112 bit work factor

This is the reason there is the expectation we have to move to EC
approaches. Longer RSA key sizes deliver diminishing returns.

The underlying problem is that the strength of RSA is strongly connected to
the distribution of primes. And even though primes become more scarce at
higher numbers, they do not become exponentially more scarce or else we
couldn't use 2048 bit RSA because it would take exponentially longer to
find the primes.

There are steps we could take to make RSA less of a burden. We could use
key compression for a start. It is actually possible to convey a 2048 bit
key in 1024 bits. We could also use one of the key compression schemes but
I am not sure if those are the source of the vulnerabilities that
discourage use of RSA.