Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-10.txt

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Apr 2020 00:41:44 +0100

Hiya,

I did an IRSG review for -09. This addresses all the issues
that I found there, except one, and that being (I think)
the most important one;-)

The issue: What is a "primary variant" and what is an
implementer supposed to do?

The above is a quote from my review of -09. Apologies if I
missed some change in -10 that addresses this.

Let me make a suggestion: state that argon2id is mandatory
to implement, and that the other variants are not. That
is language that implementers of RFCs are used to reading
and understand. An even better way to say that is to say
that "argon2id MUST be supported" and that the other
variants "MAY be supported." With the current language we
could see different implementers interpret the text in
different ways, possibly damaging interop.

Cheers,
S.

On 25/03/2020 15:08, [email-masked] 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           : The memory-hard Argon2 password hash and proof-of-work function
>         Authors         : Alex Biryukov
>                           Daniel Dinu
>                           Dmitry Khovratovich
>                           Simon Josefsson
> 	Filename        : draft-irtf-cfrg-argon2-10.txt
> 	Pages           : 20
> 	Date            : 2020-03-25
> 
> Abstract:
>    This document describes the Argon2 memory-hard function for password
>    hashing and proof-of-work applications.  We provide an implementer-
>    oriented description with test vectors.  The purpose is to simplify
>    adoption of Argon2 for Internet protocols.  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-argon2/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-argon2-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Milan Broz <[email-masked]>
Date: Thu, 9 Apr 2020 11:05:37 +0200

On 07/04/2020 01:41, Stephen Farrell wrote:
> to implement, and that the other variants are not.

Hi,

Argon2id is combination of Argon2i + Argon2d, so implementing
all three variants should be quite easy (code must be there anyway,
it is just about providing external interface to it).

I think all variants should be mandatory...  and as I understand
the current RFC draft (3.1 section), it already says so:

o  Type y of Argon2: MUST be 0 for Argon2d, 1 for Argon2i, 2 for
      Argon2id.

(We use Argon2 in cryptsetup/LUKS2 and Argon2i (not id) is
currently the primary variant for the key derivation.
For compatibility with existing devices we need support
for all three variants. But obviously, this is just one use case,
RFC is more generic.)

Thanks,
Milan

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 9 Apr 2020 12:22:14 +0100

Hiya,

> for all three variants. But obviously, this is just one use case,

I'd also be fine with all being mandatory to implement
but would prefer just one. Even if there's not much cost,
in terms of code, there would be follow on cost in terms
of assigning code-points at higher layers, and in terms
of the arguments that will ensue about which code-point
to use/assign in various contexts. Providing more options
at this level is usually a bad plan that's unfortunately
attractive to many cryptographers;-)

But my main ask is just that it be clear what's expected
of an implementer, so we get better interop.

S.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Apr 2020 14:08:48 +0100

Hi,

> On 9 Apr 2020, at 12:22, Stephen Farrell <[email-masked]> wrote:

I agree with Stephen that the draft needs to be more explicit about which variants need to be implemented. 

-- 
Colin Perkins
https://csperkins.org/