Re: [CFRG] I-D Action: draft-irtf-cfrg-spake2-24.txt

[Watson Ladd <[e-mail]>]

On Fri, Nov 26, 2021 at 1:23 PM Rene Struik <[e-mail]> wrote:
>
> Dear Watson, Ben:
>
> I did have a brief look at rev24 of the SPAKE2 draft and noticed that
> the abstract now includes the statement "This document predated the CFRG
> PAKE competition and it was not selected, however, given existing use of
> variants in Kerberos and other applications it was felt publication was
> beneficial. Applications that need a symmetric PAKE and where hashing
> onto an elliptic curve at execution time is not possible can use
> SPAKE2". I was wondering which applications would not have the
> capability to perform a hash-to-curve operation (after all, if an
> application implements elliptic-curve arithmetic, it seems unlikely it
> could not easily implement a hash-to-curve mapping). In other words,
> what am I missing?

It is important to understand that this draft has been in preparation
for 7 years, has passed multiple last calls, is really in the final
stages, so we don't have as much ability to make large changes as we
did earlier in the process. Hash to curve did not exist when it was
begun, and many applications will not incorporate it for some time.
SPAKE2 is being used in multiple places. That's why it's important to
document, and some applications will not be able to get hash2curve
everywhere, versus once to create (optionally) parameters.

>
> A few comments from rereading the draft (without trying to be exhaustive
> [I do realize this may be too late in the game, but wonder who looked at
> this stuff carefully]):
> 1) Proper naming. The draft mentions the curve P512 a few times. I
> presume this should be the NIST curve P-521 (I think I sent Watson an
> offline note on this two years ago). Shouldn't one have a proper
> reference to NIST curves (e.g., FIPS Pub 186-4) and denote these in
> slightly less sloppy way as P-256, P-384, and P-521? {The same remark
> applies to SHA2 hash function family members, which in FIPS 180-4 are
> denoted by SHA-256, SHA-384, and SHA-512.}

Thank you for catching this typo.

> 2) Representation. Table 1 of the draft refers to edwards25519 and
> edwards448, but RFC 7748 does not specify the encoding format of points
> of these curves. This leaves the transcript TT underspecified. Shouldn't
> one also specify whether one uses compressed or uncompressed formats?

We'll correct the reference to
https://datatracker.ietf.org/doc/html/rfc8032, and specify the formats
in more detail.

> 3) Test vectors. Appendix B only gives test vectors for SPAKE2 with the
> {P-256, SHA-256, HKDF, HMAC} suite. Given that Table 1 lists many more
> ciphersuites, this makes me wonder why this particular one was singled
> out in Appendix B.

This is the one kitten is likely to use.
> 4) Ciphersuites. Table 1 uses two ciphersuites with P-256, viz. one wish
> SHA-256 and one with SHA-512. What is the reason for including SHA-512?
> If this was only included because SHA-256 was deemed "too short" for key
> derivation, this seems more an artifact of the key derivation itself
> (where one partitions Hash(TT) into two half-size strings) and would be
> easily remedied by using the (already used) hkdf function for key
> derivation).

If more ciphersuites are needed we can define them in later documents.
256 bit keys are not usually used.

> 5) Security Considerations. The main construction does not mention at
> all that M and N should be elements of the prime-order subgroup (of,
> unfortunately named, order "p"), while this is required to not leak w
> (mod h), where h is the co-factor of the group. It would be beneficial
> to have a reference that illustrates why "x" and "y" cannot be reused at
> all (or a simple illustration in a sentence or two that a single repeat
> destroys security [this is not entirely obvious]).

We shall amend the security consideration accordingly.
> 6) Some small notes:
> -i) The set-up (Section 3.2) considers very general set-ups (groups in
> which the gap-Diffie-Hellman problem is hard), but then refers to
> "points at infinity" and SEC1 formatting, where the former is not
> defined for (complete) twisted Edwards curves and where the latter is
> only defined for short-Weierstrass curves. Lots of concepts are
> well-known to insiders, but not so much to others (as an example, "we
> will work in the quotient group" may make sense to people with a
> background in abstract algebra, but perhaps not too much to others.
> Moreover, there are many ways to represent elements of a quotient
> group...).

We haven't seen this pose a problem for implementors.

> ii) According to the abstract, SPAKE2 is above all useful if one does
> not have access to hash-to-curve functionality, which makes me wonder
> why (in Section 3.2, p.4, 2nd para) one suddenly invokes hash-to-curve
> concepts. Even if one would use this (seemingly superfluous) reference,
> one should then at least properly introduce notions as DST and indicate
> which of the zillions of flavors of hash-to-curve constructs one wishes
> to recommend (since you use "SHOULD", one would expect some precision
> here). If hash-to-curve is somehow used in the draft, why weren't the M
> and N parameters generated that way (rather than using the
> trial-and-error method)? This would also make it much easier for an
> implementation to check whether  and N were indeed generated that way.

Historical reasons: we shipped with hunt and peck, then later people
wanted to generate their own points and suggested hash to curve. I'm
not sure what you mean by introducing DST: we'll take a look at this
area of the text.

> iii) In the informal introduction of KDF (Section 3.2, p. 5), both ikm
> and IKM are used, while MAC is used without arguments (e.g.,
> MAC(key,msg)). Since the hash function has as output a bit string,
> shouldn't its minimum length be 256 bits (rather than 32 bytes)?

These seem like fairly simple textual clarifications.

>
>
> On 2021-11-24 5:53 p.m., [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Crypto Forum RG of the IRTF.
> >
> >          Title           : SPAKE2, a PAKE
> >          Authors         : Watson Ladd
> >                            Benjamin Kaduk
> >       Filename        : draft-irtf-cfrg-spake2-24.txt
> >       Pages           : 17
> >       Date            : 2021-11-24
> >
> > Abstract:
> >     This document describes SPAKE2 which is a protocol for two parties
> >     that share a password to derive a strong shared key without
> >     disclosing the password.  This method is compatible with any group,
> >     is computationally efficient, and SPAKE2 has a security proof.  This
> >     document predated the CFRG PAKE competition and it was not selected,
> >     however, given existing use of variants in Kerberos and other
> >     applications it was felt publication was beneficial.  Applications
> >     that need a symmetric PAKE and where hashing onto an elliptic curve
> >     at execution time is not possible can use SPAKE2.  This document is a
> >     product of the Crypto Forum Research Group (CFRG) in the IRTF.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-spake2-24
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-spake2-24
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > CFRG mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/cfrg
>
>
> --
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg



-- 
Astra mortemque praestare gradatim