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

[Luke Howard <[e-mail]>]

I reckon let's do it "properly" even if at the expense of redundant text.

Sent from my iPhone

> On 28 Jun 2016, at 11:49, Benjamin Kaduk <[e-mail]> wrote:
> 
> Thanks, Michael.
> 
> If the WG does want to treat the PRF octet-string input as a SP800-108
> context and use a zero-byte separator, it seems like the "quick-and-dirty"
> patch would be to just stick one in after "prf" and then there would be
> another (somewhat superfluous) one appended after the octet-string by
> KDF-HMAC-SHA2.  That might be easier than essentially inlining the
> definitino of KDF-HMAC-SHA2 for just the PRF calculation.
> 
> -Ben
> 
>> On Mon, 27 Jun 2016, Michael Jenkins wrote:
>> 
>> Ben,
>> 
>> we'll get started on these.
>> 
>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk <[e-mail]> wrote:
>>> 
>>> Hi Michael et al,
>>> 
>>> As I was preparing the shepherd writeup for this document, I noticed some
>>> things that do not block the progression of the document but do require
>>> changes, and one item that may require further WG input.  Can you prepare
>>> a new version with the changes mentioned below?
>>> 
>>> 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.)
>>> 
>>> Additionally, all document authors will need to confirm compliance with
>>> BCPs 78 and 79 for this document, namely that there are no intellectual
>>> property concerns with the document that are not already disclosed.
>>> 
>>> Please add a normative reference to RFC 2104 for HMAC, first mentioned at
>>> the end of Section 1.
>>> 
>>> In Section 3, it might aid clarity to mention that the 0x00000001 input to
>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is the
>>> first block of output, even though it is the only block of output as
>>> well].
>>> 
>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the
>>> function of that name from RFC 2898" after the algorithm block, since most
>>> everything else used there also gets clarified.  (It is already cited at
>>> the beginning of the section, in the overview paragraph.)
>>> 
>>> The document should be consistent about using "cipher state" as one word
>>> or two (RFC 3961 prefers the two-word form).  It also makes a rather
>>> sudden appearance at the beginning of Section 5 with no explanatory
>>> introduction; it might help the reader to instead start with "The RFC 3961
>>> cipher state that maintains cryptographic state across different
>>> encryption operations using the same key is used as the formal
>>> initialization vector [...]" On the next page, "cipherstate" is defined as
>>> "a 128-bit initialization vector derived from the ciphertext", which is
>>> potentially misleading, since it can't be both used as the IV for and
>>> derived from the same ciphertext!  Probably it's better to say "derived
>>> from a previous (if any) ciphertext using the same encryption key, as
>>> specified below".
>>> 
>>> Still in Section 5, in the definition of the encryption function (well,
>>> computing the cipherstate, really), I'm of two minds whether it's worth
>>> mentioning that the case of L < 128 is impossible because of the 128-bit
>>> confounder.
>>> 
>>> In the decryption function, can you add a note to the right of "(C, H) =
>>> ciphertext" that "[H is the last h bits of the ciphertext]"?
>>> 
>>> In the pseudo-random function, please replace "base-key" with "input-key",
>>> since the key input to the PRF is not expected to be a kerberos protocol
>>> long-term base key.
>>> 
>>> In Section 6, the "associated cryptosystem"s are supposed to be
>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere
>>> in the document.  While the meaning is pretty clear, it's probably better
>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as
>>> appropriate".  This does duplicate the preceding text, but we do want to
>>> explicitly list the "associated encryption algorithm" as listed in the
>>> Checksum Algorithm Profile of Section 4 of RFC 3961.
>>> 
>>> In Section 8.1, the acronym "TGT" is used, the only instance in the
>>> document.  It's also potentially misleading, since ticket-granting tickets
>>> are generally objects that are issued to client principals by the AS.
>>> I'd go with "Cross-realm krbtgt keys" instead.
>>> 
>>> The test vectors for key derivation have a parenthetical "constant =
>>> 0x...", but the term "constant" does not appear elsewhere in the document.
>>> The hex values are the label input for the HMAC, so we should call them
>>> that.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Ben
>> 
>> 
>> 
>> --
>> Mike Jenkins
>> [e-mail] - if you want me to read it only at my desk
>> [e-mail] - to read everywhere
>> 443-634-3951
> 
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten