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

[Kenneth G Raeburn <[e-mail]>]

Aside from the stuff Greg brought up, which all looks pretty straightforward to address, the rest looks good to me.

A couple minor things, which may or may not be worth doing anything about:

Section 8: I think one can argue that the formulation using the fixed IV and random confounder is mathematically identical to using a random IV; it’s just expressed differently, for historical reasons.  This document probably wouldn’t be the place for it, but I wonder if a formal write-up of equivalent (fully compatible) cryptosystems using a more standard approach (random IV, no confounder) and laying out the alternate formulation of all the messages (e.g., what do the checksums cover, and how does the “cipher state” fit in then?) would be a useful way to say, “Yes, see right here, these Kerberos cryptosystems really do conform to these specs; the historical formulation is just weird.”  In fact, perhaps we should have reworked them for RFC 3961.

But I digress… for this draft, what’s there is good, though I wonder if it’s straightforward enough to reassure a reader not sufficiently familiar with cryptography, or if they’ll just see “does not…comply” with NIST requirements.  Granted, most people reading it will probably figure it out, if they care, but our audience isn’t exclusively cryptographers, it’s people wanting to understand and/or implement protocols.

Section 8.1: It’d be easy enough to define an encoding to carry 128 random bits while being compatible with UTF-8; I don’t think it’s required that the 128 random bits be contiguous, is it?  It’s good to note the issue, but this is one with an easy solution.

“Some known issues…” is followed by a list of one protocol-related item.  (I would read “Further… the following issues…” as introducing a second list, of implementation issues, not a continuation of the first list.)  A list-of-one reads awkwardly; I’d suggest perhaps something like:

  … shall be randomly generated.  The string-to-key function…valid UTF-8 strings, so a UTF-8 compatible encoding would be needed to encapsulate the 128+ random bits.  However, using a salt containing a random portion may have…

Ken