Subject: [secdir] Secdir review

From: Watson Ladd <[email-masked]>
Date: Thu, 7 Jul 2016 19:56:39 -0700

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 08 Jul 2016 08:38:42 -0700

Which document is this a review of?

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Fri, 8 Jul 2016 08:59:59 -0700

draft-ietf-kitten-aes-cts-hmac-sha2

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Jul 2016 14:26:56 -0400 (EDT)

[putting the draft name in the subject line, though I am just guessing
about the -10 part]

> 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

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.

> 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.

> discusses the seriously pase rainbow table instead of GPUs for

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.

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.

> 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.

> clear to the auditor. It is an ugly solution to a self-inflicted

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.

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.

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.

> 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.

> 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.

> 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.

> 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.

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Sat, 9 Jul 2016 09:02:56 -0700

> 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.

> draft-mccallum-kitten-krb-spake-preauth-00 in the works to provide the

I think using scrypt is a much better idea to reduce the number of guesses.
> 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".

> specify *something* for it.

How about a 0 byte string?

> 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.

> 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.

> 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?

> 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.

> Suite B profile for Kerberos.

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

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