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

[Jeffrey Altman <[e-mail]>]

+1

On 6/28/2016 3:21 AM, Luke Howard wrote:
> 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
> 
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten
>