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

"Roque Gagliano (rogaglia)" <> Fri, 14 December 2012 11:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A0D221F858C; Fri, 14 Dec 2012 03:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VUmQTA7e6vR0; Fri, 14 Dec 2012 03:25:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5A3A221F8541; Fri, 14 Dec 2012 03:25:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6924; q=dns/txt; s=iport; t=1355484338; x=1356693938; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zOVe0u+zc5jrRs8p1VH/vUz4LTnOyaQzNUI+/8T6aeo=; b=LJfkNlsMS5qBmpWgoCLbM2QNoypEIiRiOdfWCwqkem6SwnlZBLOZqR3y pHjI9Lhwh7/+KNHcYdeDtYmzLHd9pOkijgMeuvWtbAFdo8YE6Kl3jzS2e FkZKiPbqbFqzRhFb0yXue6UJ0aXSBKmlTN2LqVGzAOetwcSppdzoYlF5z E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.84,280,1355097600"; d="scan'208,217"; a="152940363"
Received: from ([]) by with ESMTP; 14 Dec 2012 11:25:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qBEBPbrB029048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 11:25:37 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 05:25:37 -0600
From: "Roque Gagliano (rogaglia)" <>
To: "Brian Weis (bew)" <>
Thread-Topic: Secdir review of draft-ietf-sidr-algorithm-agility-08
Thread-Index: AQHN2Z7mAg8yZfnng0akBXDnVBP64pgYjNAA
Date: Fri, 14 Dec 2012 11:25:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F021FEC7B8xmbrcdx02ciscoc_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 14 Dec 2012 04:24:14 -0800
Cc: "<>" <>, The IESG <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Dec 2012 11:25:40 -0000

Hi Brian,

Thanks for your review. See my answers inline.


On Dec 14, 2012, at 3:00 AM, Brian Weis wrote:

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.

One clarification is that the first piece of text that you quoted is the normal agility process while the second quoted sentence refers to what to do when the new algorithm suite is deemed unsuitable and the algorithm change process needs to be canceled.

That said, what about this clarification text?

If the Algorithm Suite A (former Algorithm
   Suite B) is deemed unsuitable, the algorithm transition timeline and
   the algorithm specification documents MUST be replaced, the
   Algorithm Suite A MUST be deprecated using the process described in
   Section 10<> and CAs MUST NOT remove Suite C product sets. At this stage, RPs are still capable of processing Suite C signed products, so the RPKI is still viable.

- 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.

Thanks! Will Change for next version.