[secdir] secdir review of draft-ietf-dnsext-algo-imp-status-03

Charlie Kaufman <charliek@microsoft.com> Tue, 10 July 2012 17:13 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 77D9F21F842B; Tue, 10 Jul 2012 10:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.533
X-Spam-Level: *
X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gQb4UGHk+J6S; Tue, 10 Jul 2012 10:13:15 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9AC9B21F8525; Tue, 10 Jul 2012 10:13:15 -0700 (PDT)
Received: from mail4-ch1-R.bigfish.com ( by CH1EHSOBE003.bigfish.com ( with Microsoft SMTP Server id; Tue, 10 Jul 2012 17:11:24 +0000
Received: from mail4-ch1 (localhost []) by mail4-ch1-R.bigfish.com (Postfix) with ESMTP id DC8AC320525; Tue, 10 Jul 2012 17:11:23 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839hd25hf0ah107ah)
Received-SPF: pass (mail4-ch1: domain of microsoft.com designates as permitted sender) client-ip=; envelope-from=charliek@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ;
X-Forefront-Antispam-Report-Untrusted: CIP:; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail4-ch1 (localhost.localdomain []) by mail4-ch1 (MessageSwitch) id 1341940282451219_3930; Tue, 10 Jul 2012 17:11:22 +0000 (UTC)
Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com []) by mail4-ch1.bigfish.com (Postfix) with ESMTP id 627F5300047; Tue, 10 Jul 2012 17:11:22 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com ( by CH1EHSMHS010.bigfish.com ( with Microsoft SMTP Server (TLS) id; Tue, 10 Jul 2012 17:11:21 +0000
Received: from co1outboundpool.messaging.microsoft.com ( by mail.microsoft.com ( with Microsoft SMTP Server (TLS) id; Tue, 10 Jul 2012 17:13:35 +0000
Received: from mail65-co1-R.bigfish.com ( by CO1EHSOBE013.bigfish.com ( with Microsoft SMTP Server id; Tue, 10 Jul 2012 17:10:59 +0000
Received: from mail65-co1 (localhost []) by mail65-co1-R.bigfish.com (Postfix) with ESMTP id A9EBF2002DF; Tue, 10 Jul 2012 17:10:59 +0000 (UTC)
Received: from mail65-co1 (localhost.localdomain []) by mail65-co1 (MessageSwitch) id 1341940257518405_28944; Tue, 10 Jul 2012 17:10:57 +0000 (UTC)
Received: from CO1EHSMHS010.bigfish.com (unknown []) by mail65-co1.bigfish.com (Postfix) with ESMTP id 7C2D65602B0; Tue, 10 Jul 2012 17:10:57 +0000 (UTC)
Received: from BY2PRD0310HT003.namprd03.prod.outlook.com ( by CO1EHSMHS010.bigfish.com ( with Microsoft SMTP Server (TLS) id; Tue, 10 Jul 2012 17:10:57 +0000
Received: from BY2PRD0310MB364.namprd03.prod.outlook.com ([]) by BY2PRD0310HT003.namprd03.prod.outlook.com ([]) with mapi id 14.16.0175.005; Tue, 10 Jul 2012 17:13:16 +0000
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dnssec-algo-imp-status.all@tools.ietf.org" <draft-ietf-dnssec-algo-imp-status.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-dnsext-algo-imp-status-03
Thread-Index: Ac1eulsWmjqZCFKMTSmBiaFh8/ra9A==
Date: Tue, 10 Jul 2012 17:13:15 +0000
Message-ID: <2C287BD334E3694A83466B9C9977F7441E5C640D@BY2PRD0310MB364.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PRD0310HT003.namprd03.prod.outlook.com
X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com
X-OriginatorOrg: microsoft.com
Subject: [secdir] secdir review of draft-ietf-dnsext-algo-imp-status-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 17:13:16 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This is a short document intended to be BCP recommending algorithms to be implemented in DNSSEC component software. It explicitly does not make recommendations as to what algorithms should be configured in deployments, but only concerns the algorithms supported in software (and presumably hardware).

While the document title (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status) makes it appear that the document describes implementations as they exist today, the main focus of the document is in recommending the algorithms that should be deployed (appropriate to a BCP). It divides algorithms into four categories: MUST IMPLEMENT, RECOMMENDED TO IMPLEMENT, OPTIONAL, and MUST NOT IMPLEMENT. There is a single MUST IMPLEMENT algorithm: RSASHA1, and a single MUST NOT IMPLEMENT algorithm: RSAMD5. Nine other algorithms are divided between RECOMMENDED TO IMPLEMENT and OPTIONAL	.

I found a number of aspects of the document troubling.

First, the document does not distinguish between algorithms that are recommended for signing new DNS records vs. algorithms that are recommended for verifying existing DNS records. It's possible that this document only intends to speak to the former, but I could not find any indication of that. In order to be able to advance to use of better algorithms, we need to deploy verification software for those better algorithms long before we start signing with them. I would think that any algorithm that is RECOMMENDED TO IMPLEMENT for signing should be MUST IMPLEMENT for verification. Even RSAMD5 should be at least RECOMMENDED TO IMPLEMENT for verifiers unless there are no such signatures out there. An implementation that only supported the MUST IMPLEMENT algorithm would not be able to verify signatures on the root zone.

Second, while the document is explicit about hash algorithms, if says nothing about key sizes for the asymmetric algorithms. The world is ratcheting up RSA key sizes, and signing with a 512 bit RSA key is as bad as signing with MD5. I would think the spec should say something about minimum and maximum RSA, DSA, and DH key sizes.

Finally, having RSASHA1 as the MUST IMPLEMENT algorithm should be controversial. SHA1 is showing signs of weakness, and DNSSEC is subject to collision attacks if the attacker is allowed to provide arbitrary data for posting in some DNS record of a zone. It is possible that RSASHA1 needs to remain the BCP signing algorithm for some time going forward because there are a large number of deployed verifiers that support nothing better, but if that's true the document should say so (possibly in Security Considerations). But that is all the more reason to specify MUST IMPLEMENT for stronger algorithms in verifiers.


Section 2.1 first paragraph last sentence has bad sentence structure, making it difficult to interpret.

Section 2.1 second paragraph: "percieved" -> "perceived"