[http-auth] Barry Leiba's Yes on draft-ietf-httpauth-scram-auth-14: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-httpauth-scram-auth-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 3 --

   It sends
   the username to the server, which retrieves the corresponding
   authentication information, i.e. a salt, StoredKey, ServerKey and the
   iteration count i.

As this is written, it's not clear whether the "corresponding
authentication information" is "a salt" alone, or the whole list of
things after.  I suggest this:

NEW
   It sends
   the username to the server, which retrieves the corresponding
   authentication information: a salt, a StoredKey, a ServerKey,
   and an iteration count (i).
END

Why does the paragraph end in a colon ("and sends a ClientProof to the
server:")?

   To begin with, the SCRAM client is in possession of a username and
   password (*) (or a ClientKey/ServerKey, or SaltedPassword).

...and...

   (*) - Note that both the username and the password MUST be encoded in
   UTF-8 [RFC3629].

I suggest that splitting these up with a bunch of text in between isn't a
good way to do it.  I think this would be better:

NEW
   To begin with, the SCRAM client is in possession of a username and
   password, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey,
   or SaltedPassword).
END

There's no pressing need to use the word "MUST" there.

   Informative Note: Implementors are encouraged to create test cases
   that use both username passwords with non-ASCII codepoints.  In
   particular, it is useful to test codepoints whose "Unicode
   Normalization Form C" and "Unicode Normalization Form KC" are
   different.

It would be good to include an informative reference to the Unicode
Normalization Forms document here, so people can easily look up what NFC
and NFKC are.  It might also be good to say "Normalization Form Canonical
Composition (NFC)" and "Normalization Form Compatibility Composition
(NFKC)", rather than to use the mixed versions that you have here.

-- Section 4 --

   from the IANA "Hash Function Textual Names" registry (see
   http://www.iana.org) .

Better, I think, to use the direct URL for the registry (which is fine
with IANA):
http://www.iana.org/assignments/hash-function-text-names/