Re: [secdir] SECDIR Review of

Suresh Krishnan <> Sat, 30 June 2012 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F85621F8540 for <>; Fri, 29 Jun 2012 17:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.567
X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ReOkyDFdtRvl for <>; Fri, 29 Jun 2012 17:45:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8165C21F8526 for <>; Fri, 29 Jun 2012 17:45:15 -0700 (PDT)
Received: from ([]) by (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5U0jDH0025904; Fri, 29 Jun 2012 19:45:14 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Fri, 29 Jun 2012 20:45:07 -0400
Message-ID: <>
Date: Fri, 29 Jun 2012 20:45:06 -0400
From: Suresh Krishnan <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Phillip Hallam-Baker <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Joel Halpern <>, "" <>
Subject: Re: [secdir] SECDIR Review of
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: Sat, 30 Jun 2012 00:45:16 -0000

Hi Phil,
  Thanks for the review. Please find responses inline.

On 06/27/2012 10:20 AM, Phillip Hallam-Baker 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.
> Surprisingly for a non protocol draft, this one actually is almost
> completely security requirements. Unfortunately I find it rather hard
> to tell if the security architecture meets the security goals because
> they are not separated from each other.
> I think the document should have a section stating the security goals
> or reference another document that states them. Presumably these are
> all derived from the Nomcom RFC.

The goals are derived from RFC3777

* Section 3 Rule 6

"     All deliberations and supporting information that relates to
      specific nominees, candidates, and confirmed candidates are

* Section 5 Rule 16

"      The nominating committee should archive the information it has
       collected or produced for a period of time not to exceed its
       The implementation of the archive should make every reasonable
       effort to ensure that the confidentiality of the information it
       contains is maintained."

> The document specifies creation of a public key but not the algorithm
> or strength. Given that this is an RFP, I think it would be
> appropriate to completely and uniquely specify the cipher suite to be
> supported.

As stated in the draft, the key is generated by the Nomcom chair out of
band and not by the tool. In the example provided in Appendix A (based
on what I actually did as chair), the key used is a RSA 2048-bit key.
Since I am not even remotely close to a security expert :-), it would be
great if you can provide suggestions to put in here for future Nomcom