Subject: [TLS] Elliptic Curve J-PAKE

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Mar 2019 17:02:08 +0000

Hi all,

in context of the OPAQUE talk by Nick today at the TLS WG meeting I mentioned that the Thread Group has used the Elliptic Curve J-PAKE for IoT device onboarding.
Here is the draft written for TLS 1.2:
https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01

The mechanism is described in https://tools.ietf.org/html/rfc8236

@Nick & Richard: Have a look at it and see whether it fits your needs.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 26 Mar 2019 22:48:24 -0400

Hi Hannes,

J-PAKE is a symmetric PAKE. Both parties store the same password. It is not
suitable for most client-server scenarios where using J-PAKE would mean
that an attacker that breaks into the server simply steals all plaintext
passwords. OPAQUE is an asymmetric (or augmented) PAKE where user remembers
a password (and nothing else, including no public key of the server) while
the server stores a one-way image of the password. Security requires that
if the server is compromised, the attacker needs to run an offline
dictionary attack for each user in the database to find the password.

If what you need is a symmetric PAKE then there are better candidates than
J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08. SPAKE2 is
*much* more efficient than J-PAKE and while both J-PAKE and SPAKE2 have
proofs of security, SPAKE2 is proven in a stronger security model relative
to J-PAKE.

I am not aware of any advantage of J-PAKE over SPAKE2 - but I may be
missing something. Maybe the PAKE presentation in cfrg will clarify these
issues further.

Hugo

On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig <[email-masked]>
wrote:

> Hi all,
>
> in context of the OPAQUE talk by Nick today at the TLS WG meeting I
> mentioned that the Thread Group has used the Elliptic Curve J-PAKE for IoT
> device onboarding.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Mar 2019 09:15:00 +0000

Hi Hugo,

I raised this issue because the IoT device bootstrapping/commissioning use case was the justification for developing OPAQUE and J-PAKE. J-PAKE seems to have met the requirements by companies working in the Thread Group working on their IEEE 802.15.4 mesh network*.

As someone on the microphone mentioned, the question is really about what the requirements are for IoT device bootstrapping.

Ciao
Hannes

*: In the meanwhile the Thread Group has moved to a certificate-based model since the use of passwords was not very useful for commercial indoor lighting deployments and they didn’t want to have the user interaction needed by passwords.

From: Hugo Krawczyk <[email-masked]>
Sent: Mittwoch, 27. März 2019 03:48
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Elliptic Curve J-PAKE

Hi Hannes,

J-PAKE is a symmetric PAKE. Both parties store the same password. It is not suitable for most client-server scenarios where using J-PAKE would mean that an attacker that breaks into the server simply steals all plaintext passwords. OPAQUE is an asymmetric (or augmented) PAKE where user remembers a password (and nothing else, including no public key of the server) while the server stores a one-way image of the password. Security requires that if the server is compromised, the attacker needs to run an offline dictionary attack for each user in the database to find the password.

If what you need is a symmetric PAKE then there are better candidates than J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08. SPAKE2 is *much* more efficient than J-PAKE and while both J-PAKE and SPAKE2 have proofs of security, SPAKE2 is proven in a stronger security model relative to J-PAKE.

I am not aware of any advantage of J-PAKE over SPAKE2 - but I may be missing something. Maybe the PAKE presentation in cfrg will clarify these issues further.

Hugo

On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Feng Hao <[email-masked]>
Date: Wed, 27 Mar 2019 18:56:24 +0000

Hi Hugo,

Thanks for your comments.

Just to clarify the difference between SPAKE2 and J-PAKE - The proof of SPAKE2 depends on the assumption of a trusted setup: the discrete logarithm between the two group generators must be unknown by anyone. If a powerful adversary (3 letter agency) gathers sufficient resources and time (say 1 year) to break one instance of discrete logarithm, it will be a class attack, breaking all instances of SPAKE2 without anyone knowing it. By contrast, they can only break one session in J-PAKE, since by design the randomness is refreshed in every session rather than being built into a static setup. This explain why J-PAKE requires more computation than SPAKE2. Hope it clarifies.

Regards,
Feng

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Hugo Krawczyk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 27 March 2019 at 02:49
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] Elliptic Curve J-PAKE

Hi Hannes,

Hugo

On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes

---

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Mar 2019 21:08:11 +0100

On Wed, Mar 27, 2019 at 7:56 PM Feng Hao <[email-masked]> wrote:
> Just to clarify the difference between SPAKE2 and J-PAKE - The proof of SPAKE2 depends on the assumption of a trusted setup: the discrete logarithm between the two group generators must be unknown by anyone.

The above is not true: we rely on the common random string model, not
the common reference model. This matters for below.

>If a powerful adversary (3 letter agency) gathers sufficient resources and time (say 1 year) to break one instance of discrete logarithm, it will be a class attack, breaking all >instances of SPAKE2 without anyone knowing it. By contrast, they can only break one session in J-PAKE, since by design the randomness is refreshed in every session >rather than being built into a static setup. This explain why J-PAKE requires more computation than SPAKE2. Hope it clarifies.

I don't know of a JPAKE proof that doesn't rely on Shamir-Fiat
heuristic, which implies common random string. Your proof is in the
ROM no? Also I do not see how one recovers the password from past
sessions or recovers the negotiated key in this case: certainly an
active attack is possible knowing a relation!

>
>
> Regards,
>
> Feng
>
>
>
> From: TLS <[email-masked]> on behalf of Hugo Krawczyk <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig <[email-masked]> wrote:
>
> Hi all,
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Feng Hao <[email-masked]>
Date: Wed, 27 Mar 2019 22:36:47 +0000

Hi Watson,

When the attacker knows the relation, besides the active attack, there may
be other things he can exploit. This however is not usually analysed as by
the assumption of the proof, this should never happen.

You¹re correct that J-PAKE uses Shamir-Fiat heuristics, hence the proof is
in ROM. The key design principle in J-PAKE is based on understanding the
importance of zero-knowledge proof. The use of Shamir-Fiat heuristics to
make ZKP non-interactive is a standard technique in cryptography. In the
field of secure two/multi-party computation, ZKP is almost universally
used in every protocol. However, in the field of PAKE, to my knowledge,
J-PAKE is the only protocol that uses ZKP. On the other hand, if you think
about PAKE, it¹s fundamentally a two-party secure computation problem on
an equality function (with the side benefit that both sides produce a
common session key when the equality holds).

Cheers,
Feng

On 27/03/2019, 20:08, "Watson Ladd" <[email-masked]> wrote:

>> Just to clarify the difference between SPAKE2 and J-PAKE - The proof of
>>SPAKE2 depends on the assumption of a trusted setup: the discrete
>>logarithm between the two group generators must be unknown by anyone.
>
>>If a powerful adversary (3 letter agency) gathers sufficient resources
>>and time (say 1 year) to break one instance of discrete logarithm, it
>>will be a class attack, breaking all >instances of SPAKE2 without anyone
>>knowing it. By contrast, they can only break one session in J-PAKE,
>>since by design the randomness is refreshed in every session >rather
>>than being built into a static setup. This explain why J-PAKE requires
>>more computation than SPAKE2. Hope it clarifies.
>
>> J-PAKE is a symmetric PAKE. Both parties store the same password. It is
>>not suitable for most client-server scenarios where using J-PAKE would
>>mean that an attacker that breaks into the server simply steals all
>>plaintext passwords. OPAQUE is an asymmetric (or augmented) PAKE where
>>user remembers a password (and nothing else, including no public key of
>>the server) while the server stores a one-way image of the password.
>>Security requires that if the server is compromised, the attacker needs
>>to run an offline dictionary attack for each user in the database to
>>find the password.
>>
>>
>>
>> If what you need is a symmetric PAKE then there are better candidates
>>than J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08.
>>SPAKE2 is *much* more efficient than J-PAKE and while both J-PAKE and
>>SPAKE2 have proofs of security, SPAKE2 is proven in a stronger security
>>model relative to J-PAKE.
>>
>>
>>
>>missing something. Maybe the PAKE presentation in cfrg will clarify
>>these issues further.
>>
>>
>>
>> Hugo
>>
>>
>>
>>
>>
>>
>>
>>mentioned that the Thread Group has used the Elliptic Curve J-PAKE for
>>IoT device onboarding.
>>contents to any other person, use it for any purpose, or store or copy
>>the information in any medium. Thank you.
>>