Last Call Review of draft-ietf-kitten-aes-cts-hmac-sha2-10
review-ietf-kitten-aes-cts-hmac-sha2-10-secdir-lc-ladd-2016-07-14-00

Dear all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I am not terribly happy with the state of this document: I don't think
it is ready. Beyond the use of the verb "inputted", there are a number
of forward references or discussion of bit representation of AES keys.
I believe everyone knows what a bunch of 16 bytes as an AES key is,
which makes me wonder why this is called out specifically. The use of
32768 as a default iteration count is buried below a layer of
indirection.

random-to-key is nowhere defined, despite RFC 3961 mandating it be
defined. I think here it is supposed to be the identity. The cipher
state is a forward reference.

PBKDF2 on a human provided password with an iteration count of 32,768
is John The Ripper's breakfast. The security considerations section
discusses the seriously pase rainbow table instead of GPUs for
password cracking.

A 16 byte random value is not a nonce. A nonce is only used once. The
data maintaned in the RFC 3961 state is described as a "formal
initialization vector". Formal meaning what? Well, it is known to an
attacker ahead of the next encryption, and thus unsuited for use in
CBC based modes, but never fear: we will make the first block of the
plaintext random instead of using a properly random IV. This was
chosen for "alignment with other Kerberos ciphers". This does not
strike me as a terribly sound idea: it is not clear what the chaining
value is doing, which suggests it has been asked to serve roles not
clear to the auditor. It is an ugly solution to a self-inflicted
calamity.

Labels and contexts must not contain null bytes if we want to
guarantee injectivity. This is not discussed anywhere I can see, and
is essential to prevent keys being the same. I also question not using
HKDF to derive keys: so long as we use only 1 key derivation mechanism
with contexts ever, we can be reasonably sure that we haven't screwed
up and created related keys. Using multiple KDFs is a great way to
screw up, and passwords are the same across services, and are going to
go through similar derivation mechanisms.

The security consideration section states that truncated SHA384  to
192 bits has a security level of 192 bits. Why not truncate SHA256? Of
course this security level is really the PRF distinguishing
probability as a function of the number of evaluations: the actual
security of the scheme is weaker due to including a collision term.
What is this security level, if not numerology rooted in keysize?

Sincerely,
Watson