Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf

[Simon Josefsson <[e-mail]>]

Stephen Farrell <[e-mail]> writes:

> With apologies to the author/shepherd, I forgot about this one;-(
>
> I'm going to start IETF last call now. My own comments below can
> be handled with any other last call comments.

Thank you!

The changes mentioned below are in this commit:
https://gitlab.com/jas/ietf-scrypt/commit/6f4f3335552528994ae326a4641b179d10a31e83#diff-1

> - intro: Maybe take a look at the intro to RFC7539. I think
> it does a good job of presenting the background (for a
> similar DJB production:-) so it might be worth seeing if
> there's anything you want to copy from that.

I have added some text inspired by this.

> - intro, para 1: some more references (or one ref to a
> survey paper) would be good

I suppose you mean references for the following?

DES-based UNIX Crypt-function,
FreeBSD MD5 crypt,
GNU SHA-256/512 crypt
Windows NT LAN Manager (NTLM) hash
Blowfish-based bcrypt

I can try to find some references.  Help appreciated on what a good
reference for these would be, the FreeBSD/GNU/NTLM are proprietary and
may lack a good specification.  I did not make any change yet.

> - intro, para 2: "as Bernstein pointed out" requires a
> reference

I dropped this.  His NFS circuit integer factorization paper was
folklore 10 years ago but less so today.

> - section 13: whassup with that? why isn't the usual IETF
> boilerplate ok?

You can't copy text from RFCs into FOSS code.  Section 13 gives reader
additional rights.  Similar boiler plate have been used in a couple of
RFCs already, and from what I understand is not in conflict with any
IETF procedures.

> - section 16: saying the reader "must" follow crypto
> research is silly as you cannot ensure readers will do that
> (and you know they won't:-). I think you mean that if you
> don't keep up to date then you might miss out when issues
> are found with this algorithm. If so, saying so would be
> better.

I tried to rephrase it -- improvements welcome.

> - 17: I'm not sure the RFC editor will like references that
> only point to http://cr.yp.to/ or tarsnap.com. If you have
> better citations in addition that'd be good.

As far as I know, Salsa20 was not published at any conference or
journal, so there may not be any better references.

For the scrypt paper, maybe the conference homepage is better?  Instead
of tarsnap.com the scrypt paper would then be linked to this page:

https://www.bsdcan.org/2009/schedule/track/Hacking/147.en.html

I did not make this change yet.

/Simon