[Crypto-panel] Review of draft-hao-jpake-04 for ISE

Russ Housley <housley@vigilsec.com> Wed, 01 March 2017 18:21 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1859312964D for <crypto-panel@ietfa.amsl.com>; Wed, 1 Mar 2017 10:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xAPgi8LfZLWz for <crypto-panel@ietfa.amsl.com>; Wed, 1 Mar 2017 10:21:08 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBF712964F for <crypto-panel@irtf.org>; Wed, 1 Mar 2017 10:21:07 -0800 (PST)
Received: from localhost (localhost []) by mail.smeinc.net (Postfix) with ESMTP id E0ED8300449 for <crypto-panel@irtf.org>; Wed, 1 Mar 2017 13:21:06 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([]) by localhost (mail.smeinc.net []) (amavisd-new, port 10026) with ESMTP id 9hZn7yEOZ_I4 for <crypto-panel@irtf.org>; Wed, 1 Mar 2017 13:21:05 -0500 (EST)
Received: from [] (pool-108-45-101-150.washdc.fios.verizon.net []) by mail.smeinc.net (Postfix) with ESMTPSA id 74E9230024A; Wed, 1 Mar 2017 13:21:05 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <D4D93E57.8A4A9%kenny.paterson@rhul.ac.uk>
Date: Wed, 01 Mar 2017 13:21:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D20C124-B34C-4FE5-A003-293FB04329E3@vigilsec.com>
References: <00a06d56-5186-4150-5ba5-810e8961d2e8@auckland.ac.nz> <D4D93E57.8A4A9%kenny.paterson@rhul.ac.uk>
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/TCjwFz3dNiUA27mXW3YQbZOqYQc>
Cc: "crypto-panel@irtf.org" <crypto-panel@irtf.org>, ISE <rfc-ise@rfc-editor.org>
Subject: [Crypto-panel] Review of draft-hao-jpake-04 for ISE
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2017 18:21:10 -0000

Document: draft-hao-jpake-05
Reviewer: Russ Housley
Review Date: 2017-03-01

The Independent Stream Editor (ISE) asked the Crypto Review Panel to
review this document.  Here is my review.

Summary: Almost Ready

Once the comments below are resolved, I think that the ISE should
publish the document.

Major Concerns:

Section 2.2:  Please remove [[Q1:: ... --Hao]]

In Section 2.2, Round 2, the document says:

   ... Alice and Bob just need to ensure g1*g3*g4 != 1 mod p and
   g1*g2*g3 != 1 mod p.  ...

I realize that the probability is extremely small that either of
these values will be 1, but the specification needs to say what the
implementer should do if it happens.  My guess is go back to Round 1,
and pick new ephemeral private keys.

Please explain why UserID is included in Section 2, but not Section 3.
How does this difference impact the security offered by the two J-PAKE

Minor Concerns:

In Section 2.1, the document says:

   ...  The two communicating parties, Alice and Bob, both agree
   on (p, q, g), which can be hard-wired in the software code.  Here DSA
   group parameters are used only as an example.  Other multiplicative
   groups where the discrete logarithm problem (DLP) is intractable are
   also suitable for the implementation.

It might be useful to point to NIST FIPS 186-4, Appendix A as a way to
generate p, q, and g.  The, you can go on to say that other ways work
too.  This gives implementers algorithms to use.

In Section 2.2, the first sentence of Round 1 should explain that x1,
x2, x3, and x4 are ephemeral private keys.

In Section 3.1, you point to [NISTCurve].  That document includes
pseudo­random curves over GF(p), pseudo­random curves over GF(2^m), and
Koblitz curves.  You only name one of them.  Are all of them acceptable
here?  Also, that document includes some curves that offer only 80-bit
security, which is considered too weak today.  It is desirable for you
to include some guidance to pick a secure curve.

In Section 3.2, the first sentence of Round 1 should explain that x1,
x2, x3, and x4 are ephemeral private keys.

In Section 3.2, it says:

   ...  In practice, it is sufficient to use only the x
   coordinate as the input to KDF to derive the session key. ...

I understand the security claim; however, Alice and Bob need to do the
same thing to produce the same key.  Therefore, I suggest:

   ...  Since it is sufficient to use only the x
   coordinate as the input to KDF to derive the session key,
   the y coordinate is not provided as an input to the KDF.  ...


Section 1.2 does nit define | or |a|, but it uses them:
   o  q: a large prime divisor of p-1, i.e., q | p-1
   o  h: the cofactor of the subgroup generated by G, as defined by h
      = |E(Fq)|/n

In addition, [a, b] should be explained in Section 1.2.

Section 5 says:

   This key confirmation procedure needs to be completed in two rounds,
   as shown below.

   1.  Alice -> Bob: H(H(k'))

   2.  Bob -> Alice: H(k')

This looks like two messages, but one round.

Also, since both mechanisms are two messages (one round), the reason
for preferring the second mechanism is incorrect.

Section 6: s/latest IEEE P1363.2 standard draft D26
            /the D26 draft of IEEE P1363.2/

In Section 9.1, [I-D-Schnorr] should point to draft-hao-schnorr-05 as a