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