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

["Matt Miller (mamille2)" <[e-mail]>]

Hello All,

Thanks to Mike for submitting the update so quickly.

It appears to me that -10 addresses all the concerns raised.
Are there any objections to moving forward with IETF Last Call
with this revision?

For convenience, the latest revision can be found here:
https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10


Thanks,

- Kitten Chairs

> On Jul 3, 2016, at 03:57, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> I nearly just started the IETF last call for this, but then
> noticed these emails;-) Please ignore any status change
> emails you may have seen.
> 
> Chairs - please tell me when you want me to start IETF LC.
> 
> I did my AD review of it, and modulo this discussion being
> resolved, I think it's ready to go ahead.
> 
> Thanks,
> S.
> 
> On 28/06/16 12:58, Jeffrey Altman wrote:
>> +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
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Kitten mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/kitten
>> 
> 
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten