Re: [secdir] secdir review of draft-moriarty-pkcs5-v2dot1-01

"Xialiang (Frank)" <frank.xialiang@huawei.com> Fri, 02 September 2016 07:36 UTC

Return-Path: <frank.xialiang@huawei.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 5EF8812D0C6 for <secdir@ietfa.amsl.com>; Fri, 2 Sep 2016 00:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Level:
X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHoiEu1H9xdX for <secdir@ietfa.amsl.com>; Fri, 2 Sep 2016 00:36:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C4F12D0E2 for <secdir@ietf.org>; Fri, 2 Sep 2016 00:36:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVN67153; Fri, 02 Sep 2016 07:36:48 +0000 (GMT)
Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 2 Sep 2016 08:36:47 +0100
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.6]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Fri, 2 Sep 2016 15:36:40 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "Rusch, Andreas" <andreas.rusch@rsa.com>, "Kaliski, Burt" <bkaliski@verisign.com>
Thread-Topic: secdir review of draft-moriarty-pkcs5-v2dot1-01
Thread-Index: AdIDbtQMbJEl3m8/Q2qkTlutw9fhVABHl6EAABIQepAABcMwEA==
Date: Fri, 02 Sep 2016 07:36:40 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AFBC287@SZXEMA502-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12AFB7711@SZXEMA502-MBS.china.huawei.com> <B8387BC3FC075E4EAD935BF5752561063CFF82B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6686A3AC7EA3FF479DACDDDD98B4A62D83007D2E@MX201CL03.corp.emc.com>
In-Reply-To: <6686A3AC7EA3FF479DACDDDD98B4A62D83007D2E@MX201CL03.corp.emc.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.99.221]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AFBC287SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57C92C11.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.6, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e61c7995b6ca769d0f16e83dcfecdc7e
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LaKYl6EzK8hWIC_7_alz_STMboI>
Cc: "draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org" <draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-moriarty-pkcs5-v2dot1-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 02 Sep 2016 07:36:56 -0000

Hi all,
Thanks for your response and clarification.
I have no more comments right now.

B.R.
Frank

From: Rusch, Andreas [mailto:andreas.rusch@rsa.com]
Sent: Friday, September 02, 2016 12:53 PM
To: Kaliski, Burt; Xialiang (Frank); draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org
Subject: RE: secdir review of draft-moriarty-pkcs5-v2dot1-01

Hi Frank,

I don't have any additional things, I completely agree with Burt's responses.

I will do the changes today and post a new version (v02).

Thanks a lot for the great review, very much appreciated!

Cheers,
Andreas


From: Kaliski, Burt [mailto:bkaliski@verisign.com]
Sent: 02 September 2016 06:40
To: Xialiang (Frank); draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org<mailto:draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org>
Subject: RE: secdir review of draft-moriarty-pkcs5-v2dot1-01

Thanks for the detailed review, Frank.  My responses are included below, prefixed [BK].

I appreciate your taking the time to review this document.

The RSA/EMC co-authors may have additional responses.


n  Burt

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Wednesday, August 31, 2016 6:03 AM
To: 'iesg@ietf.org'; 'secdir@ietf.org'; draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org<mailto:draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org>
Subject: secdir review of draft-moriarty-pkcs5-v2dot1-01

Hello,

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 provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. And this document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.


In general, this draft is based on [RFC2898] (PKCS #5) and RSA new released PKCS #5 V2.1 specification, and includes some minor updates to them. So, it has a solid security basis. Regarding to the new introduced contents, there are no more new security threats identified.


Summary: this document appears in reasonably good shape, with minor issues that should be addressed before publication.


Below is a series of my comments, nits for your consideration.


comments:

Section 5.1
"S    salt, an eight-octet string": This sentence is not accurate. The Salt used in the PBKDF1 algorithm should be an octet string with more than 8 bytes length here;

[BK]  The text appears in both the source document* and RFC 2898.  However, in both places, the guidance on salt is that it should be "at least eight octets" long.  In other words, it should be at least eight octets long, but it could be exactly eight octets or shorter.  In any case, the error is an old one.  Although the authors' intent is to republish the source document essentially as is, I'd recommend to drop "eight-octet" here since it conflicts with the internal guidance.

* http://www.emc.com/collateral/white-papers/h11302-pkcs5v2-1-password-based-cryptography-standard-wp.pdf

section 5.2
"applied to the password P and the concatenation of the salt S and the block index i:": this sentence seems to be not clear to explain the following series of equations, for example:
1. how to use "i" in them?
2. how to use "Salt" in them?
Would you please clarify the issue and improve the content to be more clear?

[BK] The password P is input to every iteration.  The salt S and the block index i are only input to the first iteration.  However, P and S || INT(i) are collectively the inputs to the process of computing all the iterates.  Better text would be: "first c iterates of the underlying pseudorandom function PRF under the password P, where the first iterate is applied to the concatenation of the salt S and the block index i:"  However, I'm inclined to keep it as is because it is not incorrect, and the intent is to republish.

[BK] As you've noted below, the text was missing the line "F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c".  This covers the "exclusive-or sum of the iterates".

nits:

Abstract
1. PKCS #8 should have a reference of [PKCS8][RFC5958];


[BK] Agreed.

2. The second "-" in "password-based-key" should be removed;

[BK] Good catch.

3. If there is PKCS #5 V2.1 specification, the reference of it should be added after the content of "PKCS #5 V2.1";

[BK] OK.  The source document can be added as a final reference.

Section 1
Please split the last two words of "compatibletechniques.".

[BK] OK.

Section 2
Miss "\xor" before "bit-wise exclusive-or of two octet strings".

[BK]  Good catch.

Section 5.1
"DK = Tc<0..dkLen-1>": Tc should be T_c.

[BK]  Another good one.

Section 5.2
1. The title of Section 5.2 should be "PBKDF2";

[BK]  Thanks.

2. A calculation equation is missed here: "F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c".

[BK] Good catch.

Section 6.1.1
The title of the Section should be "PBES1 Encryption Operation".

[BK] Yes.  In table of contents as well.

Appendix A.1
"for PBES1" should be changed to "for PBKDF1".

[BK]  PBKDF1 doesn't need an algorithm identifier because PBES1 defines a different algorithm identifier for each underlying password-based key derivation function.  PBKDF2, in contrast, needs one because PBES2's algorithm identifier is modularized.   This is the reason the text says "the object identifiers for PBES1 are sufficient."  So no change is needed (and the change would be incorrect).

Thanks!

B.R.
Frank