[secdir] Secdir review of draft-jivsov-openpgp-ecc-12

Brian Weis <bew@cisco.com> Wed, 11 April 2012 03:11 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 3B2EC21F84EB; Tue, 10 Apr 2012 20:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UyJJdlsfb+sZ; Tue, 10 Apr 2012 20:11:50 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9121F84DC; Tue, 10 Apr 2012 20:11:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3353; q=dns/txt; s=iport; t=1334113910; x=1335323510; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=NZIITSJy5FdzCUhiVr7bSez9KU71cSoGDWOtl3CZYQc=; b=BDfku6AdlCrV+XAqQchCBfka94StOj3dOl4lq975vIXPjHat4zgceB1f AmE2rhwi6x3Wf8DqrDoqs7Eyl7WM8o/M/SUNdkWqJ+kQCXorPDjs02EJM 9ezm5LZHaCswRxY5L74Tf7DLfKciu84KRp2QJJlyXx71meErzUHGNcVr0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAKf1hE+rRDoJ/2dsb2JhbABFuT+BB4IiASc/gT4BNIdrmkmgI5BbYwSIWo0Sjk2BaYMH
X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="37385330"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Apr 2012 03:11:50 +0000
Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3B3BnxA011023; Wed, 11 Apr 2012 03:11:50 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Apr 2012 20:11:49 -0700
Message-Id: <C0885DDE-7014-4D5C-8B4E-4F2578BB7963@cisco.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Cc: draft-jivsov-openpgp-ecc.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-jivsov-openpgp-ecc-12
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: Wed, 11 Apr 2012 03:11:51 -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 adds support for the use of ECC as an authentication method to OpenPGP. Two public key algorithms are supported: ECDSA and ECDH. The document describes the supported ECC curves, how the public key is represented in OpenPGP, and encodings for public and private keys. For ECDH, it also specifies the KDF for creating a KEK from from ECDH shared secret and the method for key wrapping a session key that is used to protect data traffic. This seems to be standard OpenPGP practice for DH public key algorithms. A stated goal is to conform to Suite B; as far as I can tell this is achieved.

I have the following comments/questions.

Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. The definition in RFC 6090 supersedes [SEC1], and it is preferable to reference just the RFC. I suggest removing "and in [SEC1]".

Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity ("point O"), which would be better to use. This seems to be the only term in this section specific to [SEC1], so making this change should enable you to change your reference to RFC 6090 here too.

Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done?

Section 7: The use of "P" for parameters is confusing, since P was just used in Section 6 to mean "Point". It would be helpful if it were "Params" or something other name.

Section 7: It would be helpful to the reader to explain that setting ZB to "x" is using the "compact output" of the shared secret (see RFC 6090 Section 4.2).

Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader.

Section 8: This says "The key wrapping method is based on [RFC3394]". I hope is it actually "conforming to [RFC3394]", which would be a clearer statement. Is that so? If not, why?

Section 8: This section gives an example of encoding a 32-octet ASE-256 session key into 40 octets, which seems to be the input to the key wrap. My understanding of the AES key wrap defined in RFC 3394 is that the key input should be just 32 octets, where it is prepended with an 8 octet IV. This doesn't match your example though. Can this be made to match the inputs in the RFC? For example, see the example in Section 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 key, and reduce the padding for the two smaller sizes.)

Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section 9?

Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information.

Thanks,
Brian