Re: [secdir] SECDIR Review of http://tools.ietf.org/html/draft-krishnan-nomcom-tools-01

Suresh Krishnan <suresh.krishnan@ericsson.com> Sat, 30 June 2012 00:45 UTC

Return-Path: <suresh.krishnan@ericsson.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 1F85621F8540 for <secdir@ietfa.amsl.com>; Fri, 29 Jun 2012 17:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.567
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReOkyDFdtRvl for <secdir@ietfa.amsl.com>; Fri, 29 Jun 2012 17:45:15 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8165C21F8526 for <secdir@ietf.org>; Fri, 29 Jun 2012 17:45:15 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5U0jDH0025904; Fri, 29 Jun 2012 19:45:14 -0500
Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 29 Jun 2012 20:45:07 -0400
Message-ID: <4FEE4C12.6040208@ericsson.com>
Date: Fri, 29 Jun 2012 20:45:06 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
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 <hallam@gmail.com>
References: <CAMm+Lwi7W9CoNinCF+4jjygEHsph_nBmBfnbxiYR3yqZOQKFiA@mail.gmail.com>
In-Reply-To: <CAMm+Lwi7W9CoNinCF+4jjygEHsph_nBmBfnbxiYR3yqZOQKFiA@mail.gmail.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Joel Halpern <joel.halpern@ericsson.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR Review of http://tools.ietf.org/html/draft-krishnan-nomcom-tools-01
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: 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
      confidential."

* 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
       term.
       ...
       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
chairs.

Thanks
Suresh