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

Phillip Hallam-Baker <> Fri, 28 March 2014 14:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2C3F1A0813 for <>; Fri, 28 Mar 2014 07:26:57 -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 gFUfswsGUfLQ for <>; Fri, 28 Mar 2014 07:26:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) by (Postfix) with ESMTP id 04CF81A07FB for <>; Fri, 28 Mar 2014 07:26:54 -0700 (PDT)
Received: by with SMTP id y1so3708599lam.6 for <>; Fri, 28 Mar 2014 07:26:52 -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=SIb4prEIbHHfAmmDGuWz1PBZtiL+HrVjlWYzhAB6p0s=; b=PGK3uh2Qsrc6/jgA+lilaU34Z54wWT10Mgbe+BC8076pxR/7YeATw5v8FzMbL5lXdc 2eQ1HcHOGgFsxVE40K/I9wdtwYW238CtwKLOI486ckn5mdujGv+ZSsSocf9Z4ywFPMVG oOuTnLy/59/s+fwo7y5ZW8UG3NWXdsQKdnsll7YqCxK/HlkXf6vK6HOd369oLhq3QNMs c7o9phIbfm01e3/yvF7Uf9n+Iaxo+vpG1bm+0+hkrNHzX/UzQp5eVCrxib6doeLQlmfo BdMAeQRJqB+figuUoJ0JBIkO4ZWWzkIQuVKHBzBkJm1ecmVQwcZEeUGcDrZe1NLOtvZU excQ==
MIME-Version: 1.0
X-Received: by with SMTP id s7mr135539laj.48.1396016812136; Fri, 28 Mar 2014 07:26:52 -0700 (PDT)
Received: by with HTTP; Fri, 28 Mar 2014 07:26:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Fri, 28 Mar 2014 10:26:52 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Joe Abley <>
Content-Type: multipart/alternative; boundary=089e0160bb1230656904f5ab7e54
Cc: Tony Finch <>, dnsop WG <>, Paul Wouters <>, 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 14:26:58 -0000

On Fri, Mar 28, 2014 at 9:50 AM, Joe Abley <> wrote:

> On 28 Mar 2014, at 9:06, Phillip Hallam-Baker <> wrote:
> > Therefore ICANN needs to sign the root zone with 2048 before we consider
> it signed. End of story.
> Small point of clarity: the only key that ICANN maintains is the 2048 bit
> KSK, and the only signatures ICANN makes with it are over the DNSKEY RRSet.
> The 1024 bit ZSKs and signatures made by those keys are handled exclusively
> by the Root Zone Maintainer (Verisign).
> It's not clear to me that any changes would be required at ICANN to
> accommodate 2048 bit ZSKs. As I recall, every KSR that is submitted for
> processing at a ceremony is carefully tested in dry runs before the date
> anyway, so even the existing QA could continue unchanged.

VeriSign is acting on ICANN's instructions. Burt Kaliski knows how to set
an RSA key length. If they take the decision the change will be made.

The root is signed using the ZSK which is 1024 bit. Ergo it is fair to say
that the root signatures are defective.

This is not an issue of hindsight. We have been phasing out 1024 bit certs
in the WebPKI since long before the Snowden disclosure. And unlike DNSSEC
we had the excuse of a very large legacy deployment to contend with.

The RSA768 break was the signal that RSA1024 was no longer to be considered
safe. When RSA 1536 is broken it will be time to go to the ECC schemes.

The reason that I can't see any ongoing risk from RSA1024 after we complete
the transition is that I expect sensible applications will (1) simply
discard RSA1024 bit signatures as invalid and (2) discard any signature
that purports to have been made before the time that the code was compiled.

I suggest that we adopt the following strategy:

1) Have some form of formal communication from the IETF to ICANN notifying
them that the RSA1024 signing is insecure.

2) Consider ways to avoid having future security requirements being
constantly compromised by the limit of one 1500 byte response packet on

A more research oriented approach is that sites deploying DNSSEC create or
have issued an X.509v3 cert for their KSK and publish that in their zone.
That can then be used as a local trust anchor within the local network. It
can also be enrolled in Certificate Transparency.

One conclusion that should be drawn from the RSA1024 fiasco is that ICANN
is not in the business of cryptography and the current institutional
relationships are unsatisfactory. VeriSign is more than competent to make
the right decision. But the responsibility and decision power is split so
they don't actually have decision making power, nor does the IETF.