Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04

Brian Weis <> Mon, 28 March 2011 08:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39E063A6893; Mon, 28 Mar 2011 01:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.411
X-Spam-Status: No, score=-110.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QudzvCRURlPj; Mon, 28 Mar 2011 01:36:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 281303A68B1; Mon, 28 Mar 2011 01:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3304; q=dns/txt; s=iport; t=1301301505; x=1302511105; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6lzDb2dBSNCWUf2dnPYQUZRhwHehVxy9RVmiv//c+CA=; b=BJ+5NfHDvP36+fvvChd8nFlutacd6qYboBfVsXG0B3qlJN0NR46zJ7kA 6EuKdKEIIX7YAxZlMXu94YHml/AXgHW6mP4G9PEQJJIUlqqg5m/+57Zls L7PB3IQHW+P78l5WzOwj62Cp+xwURNXt75pnOvR3qDKq7t8ebzSF8QWt6 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAElIkE2rRDoH/2dsb2JhbAClSneIa50RmyyDFoJTBIU6hz2DVA
X-IronPort-AV: E=Sophos;i="4.63,253,1299456000"; d="scan'208";a="419277841"
Received: from ([]) by with ESMTP; 28 Mar 2011 08:38:25 +0000
Received: from [] ([]) by (8.14.3/8.14.3) with ESMTP id p2S8cNhD030311; Mon, 28 Mar 2011 08:38:24 GMT
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Brian Weis <>
In-Reply-To: <p06240804c9b5ec3f841b@[]>
Date: Mon, 28 Mar 2011 01:38:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <p06240804c9b5ec3f841b@[]>
To: Stephen Kent <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Mar 2011 08:36:49 -0000

Hi Steve,

On Mar 28, 2011, at 12:47 AM, Stephen Kent wrote:

> At 1:37 PM -0700 3/27/11, 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 the algorithm suite used as part of the RPKI. The suite specifies a single signature algorithm (RSA) with a single key size, a single hashing algorithm (SHA-256), a single signature format, and formats for describing the public key. Section 5 indicates that this profile will be updated when the RPKI needs to adapt different choices. I was glad to see such an algorithm agility plan, but this implies that this will in fact never have a peer document describing another profile. In such a case I would expect the document title to be more inclusive (e.g., drop the first three words of the title). Alternatively, it might be helpful to describe in Section 5 under what circumstance another profile would be published instead of updating this one.
>> The Security Considerations document refers the reader to the security considerations described in several other documents. After reading those sections, I agree this is appropriate.
>> Brian
> Brian,
> There will be another profile that will define two sets of algs, current and next.  See daft-sidr-algorithm-agility-00.txt for the description of how alg migration is anticipated to work.

I had looked through the algorithm-agility document before commenting but didn't see that it declared that a new profile would be generated. Your description of ("two sets of algs, current and next") seems to match the intent of Section 5, such that it would be an update to this same profile. Here's the text in question:

  "It is anticipated that the RPKI will require the adoption of updated
   key sizes and a different set of signature and hash algorithms over
   time, in order to maintain an acceptable level of cryptographic
   security to protect the integrity of signed products in the RPKI.
   This profile should be updated to specify such future requirements,
   as and when appropriate."

When I read 'updated' I assume it means it adds to the same profile, and the subsequent 'update' will be published under the same name as the original. Is that your intent?

> I hesitate to put a (normative) reference to that doc in here, because it is not yet approved and might slow down the
> set of SIDR docs that rely, normatively, on the doc that you reviewed.

Understood, and I didn't mean to imply a normative reference was needed -- just an informational explanation of why a different profile might be needed rather than an update to this one. But if that isn't actually expected, then I was questioning why the title implied there would in fact be independent profiles.


> Steve

Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796