Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09

[Benjamin Kaduk <[e-mail]>]

On Mon, 27 Jun 2016, Luke Howard wrote:

> > The one item which would potentially affect the actual protocol: at the
> > end of Section 5, the pseudo-random function seems to be using a SP800-108
> > KDF but omits the zero byte between label and context.  I think it would
> > be better to have the zero byte -- do you remember whether there was a
> > reason to omit it?  (Adding the zero byte would require re-rolling some
> > test vectors, to be clear.)
>
> The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts
> the zero byte when invoking HMAC-SHA-256(), e.g.:
>
> 	PRF = KDF-HMAC-SHA2(base-key, "prf" | octet-string, 256)
> 	= k-truncate(HMAC-SHA-256(key, 0x00000001 | "prf" | octet-string | 0x00 | 256))
>
> if I’m not mistaken? Pretty sure our implementation passed the test vectors.

I think that SP800-108 would have it be

[counter] | [label] | 0x00 | [context] | [output-length]

with the NUL between label and context, not between context and
output-length.

Its definitions are:

%%%%%%%%%%%

3) Label
 A string that identifies the purpose for the derived keying material,
which is encoded as a binary string. The encoding method for the Label is
defined in a larger context, for example, in the protocol that uses a KDF.

4) Context
 A binary string containing the information related to the derived keying
material. It may include identities of parties who are deriving and/or
using the derived keying material and, optionally, a nonce known by the
parties who derive the keys.

%%%%%%%%%%%

For the PRF, the octet-string input is pretty clearly something
specifically known to the parties who derive the keys, which seems like a
context.

For the use of KDF-HMAC-SHA2 elsewhere in the document, e.g. for deriving
Kc, Ke, and Ki, the line between label and context is less clear, since we
invoke it as (e.g.)

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128)

and the 0x99 is defined by the protocol and would plausibly still be part
of the label.

As I recall, the PRF was something of a late addition, and if the
KDF-HMAC-SHA2 construct was defined originally for password key derivation
and deriving Kc/Ke/Ki, that would explain why there was not thought about
having a proper SP800-108 context that would also need separation.
(SP800-108 has the context as optional ("One or more of these fixed input
data fields may be omitted unless required for certain purposes as
discussed in Section 7.5 and Section 7.6."), which is fine and would apply
for the non-PRF cases here.)

-Ben