[lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10

Roman Danyliw <rdd@cert.org> Mon, 03 June 2019 18:33 UTC

Return-Path: <rdd@cert.org>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 88ACB1201D0 for <spasm@ietfa.amsl.com>; Mon, 3 Jun 2019 11:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Sftnkvx17Puv for <spasm@ietfa.amsl.com>; Mon, 3 Jun 2019 11:33:27 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88B512007C for <spasm@ietf.org>; Mon, 3 Jun 2019 11:33:27 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu []) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x53IXQTX020116 for <spasm@ietf.org>; Mon, 3 Jun 2019 14:33:26 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x53IXQTX020116
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559586806; bh=QdQob1IwUfXm6EFwcVvAEsy01pwm0D4P0FWpwTSsbms=; h=From:To:Subject:Date:From; b=fySPCx+9lXDOmg3BqZiQFs8DwXRt3cSGkWExX5qzhi6Uga0DRa6JOaeqNEnz3Eoqh vhwTLRfHvfOoIwCqmzwDT9RITup0c9eKOXX8/75J2y7vXPf5VRcYlgoicP8Ztx1/+y I686QBG/jXT9jgKNaAU7FcZ+rqx8DqFVYATcw1gU=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu []) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x53IXMK8008893 for <spasm@ietf.org>; Mon, 3 Jun 2019 14:33:22 -0400
Received: from MARATHON.ad.sei.cmu.edu ([]) by CASSINA.ad.sei.cmu.edu ([]) with mapi id 14.03.0439.000; Mon, 3 Jun 2019 14:33:22 -0400
From: Roman Danyliw <rdd@cert.org>
To: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: Second AD Review: draft-ietf-lamps-pkix-shake-10
Thread-Index: AdUaOicKPUSplJFAQJW7VEoVRR7HXg==
Date: Mon, 3 Jun 2019 18:33:22 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B338267A@marathon>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/3tX9RC2ec7MQQ3iRsuzFLVqiSOA>
Subject: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2019 18:33:30 -0000


As a document I inherited in the "IESG:: Waiting for Writeup Internet-Drafts", I conducted a second AD review on draft-ietf-lamps-pkix-shake-10.  I have the following feedback:

(1) Header. Per idnits:    == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list.

s/Updates: RFC3279/Updates: 3279/

(2) Additional References Needed

(2.a) Section 2
   And, the
   corresponding collision and second preimage resistance strengths for
   SHAKE256 are min(d/2,256) and min(d,256) bits respectively.

Recommend you cite Section A.1 of [SHA3] as the source of these security strength metrics.

(2.b) Section 2
   A SHAKE can be used as the message digest function (to hash the
   message to be signed) in RSASSA-PSS and ECDSA  and as the hash in the
   mask generating function in RSASSA-PSS.

Provide a reference on first use for RSASSA-PSS [RFC8017] and ECDSA [X9.62]

(3) Editorial
(3.a) Section 5.1
   In an
   X.509 certificate a signature is encoded  with an algorithm identifier
   in the signatureAlgorithm attribute and a signatureValue  that
   contains the actual signature.

s/signatureValue/signatureValue attribute/

(3.b) Section 5.1.1.  Add commas between terms.  

s/hash and mask generating algorithm and trailer and salt are embedded in the OID definition/
hash, mask generating algorithm, trailer and salt are embedded in the OID definition/

(3.c) Section 5.1.1.  Define the acronym MGF on first use

s/mask generation function/mask generation function (MGF)/

(3.d) Section 5.1.  Duplicate word.  s/section Section 4/Section 4/

(4) Section 5.1.  The ASN.1 blob of Certificate is inserted in the text without citation or explanation.  It seems like the paragraph prior to it should make explicit reference to it (as it cites the elements).

(5) Section 5.1.
   MAY also generate such signatures in accordance with all other
   recommendations in [X9.62] or [SEC1] if they have a stated policy
   that requires conformance to these standards.  These standards may
   have not specified SHAKE128 and SHAKE256 as hash algorithm options.
   However, SHAKE128 and SHAKE256 with output length being 32 and 64
   octets respectively are substitutions for 256 and 512-bit output hash
   algorithms such as SHA256 and SHA512 used in the standards.

I recommend being more precise in this text.

s/These standards may have not specified SHAKE128 and SHAKE256 as hash algorithm options./
These standards have not specified SHAKE128 and SHAKE256 as hash algorithm options./

Per "SHAKE128 and SHAKE256 with output length being 32 and 64 octets respectively are substitutions for ... SHA256 and SHA 512", what does substitutions mean in this case?  Similar output size or cryptographic strength?