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

Paul Wouters <> Wed, 02 April 2014 15:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FFA81A0298 for <>; Wed, 2 Apr 2014 08:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JaA8eEGNH_NL for <>; Wed, 2 Apr 2014 08:38:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5437F1A028A for <>; Wed, 2 Apr 2014 08:38:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E9306813B5; Wed, 2 Apr 2014 11:38:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1396453120; bh=p4JCeW82YN8BG+Djs5Or0Dpa4xgZyIvbs6Phkq01qcA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kqt0XsMvmUAw4m6UMvM5tkiXbbxzpWMU4YEE60PEo+DThNwBAucc02Gs/ssYUoV6E momLASiS2Mah5ts7SZ6upTe3AyFUq64S8CzVFKLJrO9YI3bXeiXXwhC3KTZ5fUHQEo t/UmowQd7xjuzPJivi8do+iyknPfTJF8UuCOBtds=
Received: from localhost (paul@localhost) by (8.14.7/8.14.7/Submit) with ESMTP id s32Fcdsv013203; Wed, 2 Apr 2014 11:38:39 -0400
X-Authentication-Warning: paul owned process doing -bs
Date: Wed, 2 Apr 2014 11:38:39 -0400 (EDT)
From: Paul Wouters <>
To: Nicholas Weaver <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <knJn1n01E0xxhYs01nJoHJ> <> <>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: "" <>
Subject: Re: [DNSOP] Current DNSOP thread and why 1024 bits
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: Wed, 02 Apr 2014 15:38:50 -0000

On Wed, 2 Apr 2014, Nicholas Weaver wrote:

> Well, its because for the most part, cryptographers do seem to understand that DNSSEC is a bit of a joke when it comes to actually securing conventional DNS records.

Funny, the cryptographers I talk to, like at the University of Waterloo,
have always told me our key sizes are giant for the deployment time we
are using them and that we're far above minimum.

> And the NIST crypto recommendations have existed for years.  1024b RSA was "deprecated in 2010, eliminate completely in 2013".  There may be doubt in NIST now, but 2 years ago, to ignore the standard recommendations is foolish.

I love how people now cherry pick NIST. If it agrees with them they
quote it. If it disagreed with them they shout NSA subverted them.

> Do your resolvers have protection against "roll back the clock" attacks?  If not, you do not "gain protection" from the short-lived (well, really, a few month, they don't roll the actual key every 2 weeks) nature of the ZSK for root, .com, etc.

Yes, there is a 5011 unbound anchor verification on some of them. And
ntpd doesn't let you jump months in a second either, so only systems
that run ntpdate before ntpd are vulnerable, and only those systems
without a battery backed up clock should do that.

>> Saving space and time does matter.  Roughly half the operators I studied would include a backup key on-line because “they could” with the shorted length.  And performance does matter - ask the web browser people.

Because we want to make security decisions based on a 1ms latency browser war?

> Amdahl's law seems to be something that computer science in general always seems to forget.  The performance impact, both in size and cryptographic overhead, to shift to 2048b keys is negligible in almost all cases.

Mind you, I agree we can move to 2048 for ZKSs

> And the step function in DNS cost, the "Internet can't do fragments" problem, doesn't really come into play at 2048b.

I don't think the entire cannot do fragments issue is really still a big
problem. Networks using/depending on has actually cleaned up a
lot of the transport issues involved I think.

>> It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation.
> Yes they have.  2048b.

Actually my Waterloo cryptographer said you can pick something smaller
than 2048 and larger than 1024 too.

> DNSSEC is actually useless for, well, DNS.  A records and the like do not benefit from cryptographic protection against a MitM adversary, as that adversary can just as easily attack the final protocol.

You are mixing in local vs global attacks. For example, Brasil's attack
where the majority of cable modems got their DNS setting changed for
their DHCP server. If hosts were running DNSSEC with using their ISP
as forwarders, this massive attack affecting millions would have
failed. So your statement is rather simplistic and wrong.

> Building the root of this foundation on the sand of short keys, keys that we know that are well within range for nation-state adversaries, from the root and TLDs is a recipe to ensure that DNSSEC is, rightly, treated by the rest of the world as a pointless joke.

Actually, I would LOVE to see a rogue entry signed by the root ZSK. It's
a giant enigma problem if the USG can make these. Please do invite me to
the root-servers meeting following that exposure.

I don't think there is a reason not to switch to 2048 for ZSKs. But I'm
basing that on "there are no significant transport obstacles left".