Re: [kitten] Comments on draft-ietf-kitten-password-storage-04

[Jim Fenton <[e-mail]>]

On 1 Apr 2021, at 14:02, Sam Whited wrote:

> Thank you for your feedback! I think I have addressed all of these
> issues (and will upload a new version soon) except for:
>
> On Sat, Mar 20, 2021, at 20:31, Jim Fenton wrote:
>> 4.1: I’m concerned that the MUST NOT here conflicts with the SHOULD
>>      NOT regarding OBSOLETE and LIMITED mechanisms in Section 2. Of
>>      course, MD5 is not an SASL mechanism per se, and “support any
>>      mechanism” in this context may not necessarily mean an SASL
>>      mechanism, but I still found this vaguely confusing.
>
> I thought of this as just further refining the guidance from section 
> 2.
> You SHOULD NOT use anything from a specific list, and MUST NOT use
> anything that meets these criteria (which may include things that are 
> on
> the list and things that aren't). However, perhapse the SHOULD NOT in
> section 2 should become a MUST NOT? Re-reading it I'm not sure why I 
> put
> SHOULD NOT there.

I haven’t looked at the specific mechanisms that might be marked 
OBSOLETE or LIMITED, but making that a MUST NOT would ensure that there 
aren’t conflicting requirements. If you do want to have one 
requirement refine the other, it would be better put them together and 
connect them with an “and”.

>> 5.2: Bcrypt is no longer the current (top) OWASP recommendation.
>
> Interestingly, I had argon2id as the top recommendation in an
> earlier draft of this document then they changed it back to bcrypt.
> I'll swap it back.

More generally, it’s probably not a good idea to cite the “current 
OWASP recommendation”, because that will probably change over time, 
while the RFC resulting from this draft won’t.

>> 7: Suggest saying something about Unicode characters and password
>>    length
>
> Good idea. I updated this to suggest counting grapheme clusters,
> which I believe is going to be better than counting scalar values,
> but I'm not sure that it's ideal either. Many languages probably
> don't have an implementation of the segmentation algorithm, and it
> adds a lot of complexity to calculating password lengths. Other
> suggestions welcome. Because of the uncertainty I did not use any
> normative language here for now.
>
> I also couldn't find an existing reference for Unicode Standard Annex
> reports. Is there a bibliography somewhere that includes these which I
> could reference instead of making up a new ref?

There’s a reference at 
https://pages.nist.gov/800-63-3/sp800-63b.html#ISOIEC10646 but I see 
that it no longer works. I’ll look around for a better one.

-Jim