Re: [secdir] Secdir review of draft-ietf-kitten-aes-cts-hmac-sha2-10

[Watson Ladd <[e-mail]>]

On Fri, Jul 8, 2016 at 11:26 AM, Benjamin Kaduk <[e-mail]> wrote:
> [putting the draft name in the subject line, though I am just guessing
> about the -10 part]
>
> On Thu, 7 Jul 2016, Watson Ladd wrote:
>
>> 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
>
> It's called out specifically because this document is (for better or for
> worse) mirroring some parts of the structure of RFC 3962.  It would
> probably be fine to remove it, but neither does it seem like it really
> matters.
>
>> 32768 as a default iteration count is buried below a layer of
>> indirection.
>
> I've lost you on that one (the indented algorithm has the default inline),
> but I'm sure the authors would be happy to look at wording suggestions.

The code shows the parameter is an iteration count, but the text
doesn't indicate this clearly.

>
>> 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.
>
> Section 5 has:
> random-to-key function: identity function
>
> That there is such a function is part of the Kerberos background knowledge
> that the reader is assumed to have, and the details of it are not relevant
> in the earlier occurrences; it's just a sigil for the type change from bit
> string to protocol key.
>
>> 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.
>
> Do you recommend a different number?  Myself, I think that the iteration
> count is not terribly important, and that switching to a PAKE-based
> preauthentication scheme that does not expose the password-derived key on
> the wire should be a higher priority than mucking around in individual
> encryption type specifications.  The current state of password-derived
> keys for Kerberos is kind of lousy, but this document is mostly just
> intended to be an incremental improvement in the hash function; we have
> draft-mccallum-kitten-krb-spake-preauth-00 in the works to provide the
> long-term fix.

I think using scrypt is a much better idea to reduce the number of guesses.
>
> Do you think that GPUs possess some magical property that excludes them
> from being covered by "password guess attempts"?  Yes, they are faster,
> but ... computers are always getting faster.

How about some actual thought about how many guesses GPUs actually
produce, today, and how large password dictionaries can be that
informs the correct number? There is lots of evidence of the form "we
dumped 10 million passwords, and this is how many the world could
crack", and the decisions about defaults need to take this into
account. It's not enough to say "oh, people can guess passwords".

>
>> A 16 byte random value is not a nonce. A nonce is only used once. The
>
> ... huh?  I assume you are referring to Section 5, "[t]he plaintext
> is prepended with a 16-octet random nonce generated by the message
> originator, known as a confounder.", and am not sure what word you would
> rather be used to describe the confounder.
>
>> 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.
>
> Fortunately, the RFC 3961 cipher state is mostly unused in practice.
> Nevertheless, it is part of the protocol, and an RFC 3961 enctype has to
> specify *something* for it.

How about a 0 byte string?

>
> You seem to be mixing several comments/objections together in that
> paragraph; hopefully I can separate them all.
>
> With regard to "formal", are you suggesting to just remove the word?  I do
> not think that doing so would cause harm to the document.
>
> Then there's something about chaining from one encryption to another,
> though I'm not sure I am really following your point.  I wasn't around at
> the time, but I assume in the early days of kerberos someone thought it
> would be clever to extend CBC chaining across encryption flows.  It
> wasn't, but we haven't gotten rid of that part of the protocol yet, so we
> do (basically) the same thing that every other enctype does.

This document defines a new way to encrypt, no? It can change this
detail. Nothing says you can't make it a useless argument.

>
> Finally, there's a concern about using a random IV versus a random
> confounder as the first block of plaintext.  This was extensively
> discussed by the WG (the original proposal was even to use a random IV),
> https://www.ietf.org/mail-archive/web/kitten/current/msg04348.html is
> perhaps a useful entrypoint to the archive.  Basically, the belief is that
> there is no difference in confidentiality and integrity protection between
> the two, and so there is a tradeoff between an extra block to en/decrypt
> and exposing the RNG output to passive observers.  This is the direction
> the WG landed in, though if you want to re-raise the issue during IETF
> last-call, that's your prerogative.  But if you do, please provide a clear
> argument instead of vague allusions to alleged best-practice.

So you believe that AES is indistinguishable from random, but don't
believe in random number generators? That's a pretty interesting pair
of beliefs to hold. Of course the excuse offered is that the RNG might
be corrupted: but the random data is exposed to clients, who can go
ahead and mount the attack.

The fact is that right now understanding why the protocol is secure
requires looking at the details of CTS. If the IV had been properly
chosen as random, this wouldn't be required; it would be enough to
know that CTS is a secure IV based mode. This is a much better state
of affairs.

Encrypt the chained value and use the result as an IV, and drop the
random data used as a "nonce", and it's just as efficient in block
cipher calls, and doesn't depend on details of CTS, and doesn't expose
random data.

>
>> Labels and contexts must not contain null bytes if we want to
>> guarantee injectivity. This is not discussed anywhere I can see, and
>
> That's a fair point, and it should probably be mentioned.  Unfortunately,
> the label is going to include the kerberos key usage number, which starts
> with a few nul bytes [see the test vectors].  Kerberos key usage numbers
> are maintained in a registry (not yet under IANA control) and are encoded
> as unsigned 32-bit integers.

Yeah, so we need to make sure the encoding is injective. There will be
some ugly details involved in figuring out if this is the case. Maybe
length-prefixing each part?

>
>> 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.
>
> That argument seemes to apply to any protocol wishing to perform key
> derivation.  I am not aware of any IETF consensus document that indicates
> we should prefer one over the other, and do not see why this document is
> an appropriate forum in which to have such a debate.  Is there something
> particular this document that would make HKDF more appropriate for it than
> SP800-108?  Do note that there are multiple implementations of the
> protocol in -10 that are ready to ship, so to me there is an extra barrier
> to making a breaking change at this stage of the document lifecycle.

We should just use HDKF everywhere instead of yet another "concatenate
this here, put that there" scheme. The problem is that any system
where the user uses the same password needs to have its scheme
compared to this one, and I am not volunteering.

>
>> The security consideration section states that truncated SHA384  to
>> 192 bits has a security level of 192 bits. Why not truncate SHA256? Of
>
> At risk of being trite, box-ticking auditors want to see SHA384.
>
>> 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?
>
> To some extent, it is just numerology, yes, but the main intent of that
> statement is to remind people to ignore the "256" in "aes256" and use the
> "192" in "sha384-192" for their numerology.  Other considerations will
> weaken things slightly, but if we did our job correctly, only slightly.
> If you have suggestions for ways to phrase that sentiment that do not have
> the failings you identify, we would be happy to see them.
>
> See also, uh,
> https://www.ietf.org/mail-archive/web/kitten/current/msg04275.html or
> thereabouts; there is supposedly some Suite B preference for sha384 at the
> 192-bit level of security, and this document is intended to support a
> Suite B profile for Kerberos.

The collision resistance of the hash function is irrelevant to HMAC
security, but whatever: the DOD wants it.
>
> -Ben



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.