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

From: Russ Housley <[email-masked]>
Date: Wed, 1 Mar 2017 13:21:08 -0500

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.

---

From: Nevil Brownlee <[email-masked]>
Date: Tue, 28 Feb 2017 16:12:15 +1300

Hi Kenny:

Thanks for that; I'm sure that people on CFRG know they can find
drafts using the DataTracker.

I'm sorry I gave names of older versions of these two drafts, Please
review the latest version of these drafts, i.e.
   draft-hao-jpake-05 and draft-hao-schnorr-05

Cheers, Nevil

On 27/02/17 3:23 pm, Paterson, Kenny wrote:
> Dear Nevil,
>
> I've forwarded your message to the CFRG review panel (cc-ed)
>
> Could you follow up by giving some pointers to the two drafts so that
> individual panel members can take a look and see if they are able to
> provide reviews?
>
> Many thanks,
>
> Kenny
>
> On 26/02/2017 23:21, "Cfrg on behalf of Nevil Brownlee"
> <[email-masked] on behalf of [email-masked]> wrote:
>
>>
>> Hi CFRG Review Panel members:
>>
>> I don't have a mail alias for the review panel, so I'm sending to
>> the CFRG list.
>>
>> These two drafts have been sent to me as Independent Submissions,
>> please review them for me.
>>
>> Cheers, Nevil
>>
>> --
>> ---------------------------------------------------------------------
>>  Nevil Brownlee                          Computer Science Department
>>  Phone: +64 9 373 7599 x88941             The University of Auckland
>>  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
>>
>> _______________________________________________
>> Cfrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand