Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

[Greg Hudson <[e-mail]>]

I did another read-through of the draft.  I found some minor issues,
which I hope can be resolved without requiring another WGLC.

* There is no specification of how to read the string-to-key parameter.
 RFC 3962 says, "The parameter string is four octets indicating an
unsigned number in big-endian order," but this draft does not reference
the RFC 3962 string-to-key and just says "iter_count = string-to-key
parameter (default is decimal 32768 if not specified)".  I assume the
intent is to be consistent with RFC 3962.

* Section 5 says "specific key structure: three protocol-format keys: {
Kc, Ke, Ki }".  Kc, Ke, and Ki are not protocol-format keys; Kc and Ki
don't even have the same length for aes256.  I suggest "three derived keys."

* Section 8 says, "The salt and iteration count resist brute force and
dictionary attacks, however, it is still important to choose or generate
strong passphrases."  This is a run-on sentence; the comma preceding
"however" should be a semicolon.

* Section 8.1 says, "The string-to-key function as defined in [RFC3961]
requires the salt to be valid UTF-8 strings."  This sentence should end
with "a valid UTF-8 string."

* Section 8.1 says, "ktutil's add_entry command assumes the default
salt."  That might be too specific; I suggest "Some key table
manipulation programs assume the default salt when adding entries based
on passwords."