[secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08

Brian Weis <bew@cisco.com> Fri, 14 December 2012 02:00 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F54E21F8A96; Thu, 13 Dec 2012 18:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level:
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCwfLeV54kp2; Thu, 13 Dec 2012 18:00:41 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7E21F8A6F; Thu, 13 Dec 2012 18:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1636; q=dns/txt; s=iport; t=1355450441; x=1356660041; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=xhLFq78Q3wr4xjx3Qu9jApflqjBD6qbHk983q+Md+mc=; b=CFtazoSnyX13F/dNRhOSICLfGGO3ZAvj5X7/Scn0SnlNwe6a814uX3UE 1ZtjRV6QQgvVEk1rPxpcJ74mwzlGjqy+CPLp5bzmbDoNt40qfItHYFgOJ qFDDjGkN8jg0JOGywwz4oYYdgG4NpBhOFLiuAzkjAWaHeJE5rd+4IlelT o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYHAC2HylCrRDoI/2dsb2JhbABFg0i7KxZzgl86BYE+ASuHeQG9I5A5YQOIYI0pkEiDFIFDAh4CBA
X-IronPort-AV: E=Sophos;i="4.84,277,1355097600"; d="scan'208";a="66514452"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 14 Dec 2012 02:00:41 +0000
Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBE20e0u015616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 02:00:40 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Dec 2012 18:00:41 -0800
Message-Id: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Cc: draft-ietf-sidr-algorithm-agility.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08
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: Fri, 14 Dec 2012 02:00:41 -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 document describes a mandatory algorithm transition procedure for the RPKI. It describes a single method, comprised of four phases and six milestones. Each phase discusses a strategy for rollback of the new algorithm. The algorithm transition procedure seems complete, and the security considerations section is adequate.

One statement in the discussion of Phase 4 is confusing (Section 4.7). It first states:

  "RPs MAY validate signed product sets
   using Suite C. However, RPs SHOULD NOT assume that the collection of
   Suite C product sets is complete."

Later it notes that Suite A could be deprecated, and states:

  "At this stage, RPs are still capable of processing Suite
   C signed products, so the RPKI is still viable."

But if the Suite C product sets may be incomplete, how is the RPKI still viable? This should be clarified.

Nits:
- Section 3, "Corresponds" definition: s/Resoureces/Resources/
- Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/
- Section 7, last paragraph. The final sentence would be clearer if it read "Since Suite C products are being deprecated during Phase 4, a CA may revoke certificates issued under Suite C without revoking them under Suite A." Ignore if you don't agree.

Brian