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

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

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>
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
Precedence: list

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
mechanisms?


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
pseudorandom curves over GF(p), pseudorandom 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.  ...

Nits:

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
work-in-progress.

Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Paterson, Kenny
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Stanislav V. Smyshlyaev
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Paterson, Kenny
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Tibor Jager
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Russ Housley
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Paterson, Kenny
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Paterson, Kenny
[Crypto-panel] Review of draft-hao-jpake-04 for I… Russ Housley
Re: [Crypto-panel] [Cfrg] ISE needs reviews for d… Nevil Brownlee