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

[Benjamin Kaduk <[e-mail]>]

Thanks for the review, Greg.

On Fri, 15 Jan 2016, Greg Hudson wrote:

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

Assuming that the intent is to be consistent with RFC 3962 for the
string-to-key parameter, I expect that these notes can be resolved without
the need for an additional WGLC.

-Ben

> * 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."
>
>