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

Benjamin Kaduk <kaduk@MIT.EDU> Fri, 08 July 2016 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19ABB12D678; Fri, 8 Jul 2016 11:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ODBep5tPqunY; Fri, 8 Jul 2016 11:27:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E48612D828; Fri, 8 Jul 2016 11:27:03 -0700 (PDT)
X-AuditID: 12074425-207ff7000000206a-de-577ff075c429
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E8.79.08298.570FF775; Fri, 8 Jul 2016 14:27:02 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id u68IR0Op023490; Fri, 8 Jul 2016 14:27:00 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id u68IQumo015142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jul 2016 14:26:59 -0400
Received: (from kaduk@localhost) by ( id u68IQuUm012924; Fri, 8 Jul 2016 14:26:56 -0400 (EDT)
Date: Fri, 08 Jul 2016 14:26:56 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Watson Ladd <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrFv2oT7cYNlTMYvX1+ayW8z4M5HZ 4sPChywWPZ0n2RxYPHbOusvusWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlfNnxk7XggH3F vKfbWBoYpxl3MXJySAiYSMw78puli5GLQ0igjUni7N6tjBDOBkaJhcf7mCGcg0wSk78sYe9i 5ABy6iWerJIC6WYR0JJY/qCLHcRmE1CRmPlmIxuILSKgLjFh+SYWEJtZoFzi4YnpYK3CAv4S X49GgIQ5BQIl5rUeB2vlFXCQ2DZ7ESOILSQQIPGnqw9sjKiAjsTq/VNYIGoEJU7OfAI1Emjt 9G0sExgFZiFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyMoWNld VHcwzvnrdYhRgINRiYc34kJ9uBBrYllxZe4hRkkOJiVR3n3PgEJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeAXfAOV4UxIrq1KL8mFS0hwsSuK8jAwMDEIC6YklqdmpqQWpRTBZGQ4OJQle5vdA jYJFqempFWmZOSUIaSYOTpDhPEDD34HU8BYXJOYWZ6ZD5E8xKkqJ834ASQiAJDJK8+B6wclk N5PqK0ZxoFeEea++A6riASYiuO5XQIOZgAYbBIANLklESEk1MCr/XPZS4Of+CS4pkax+uu5+ cd+7Fr8Me/A3v3+poBPr4cOyjSyVpY2zjP2U2+4tcdqzsUz1h9Dq/qyVfx6tdX436Wjyh7ly F3fkikzMXKgw2bpJZN+ftvyWK8vb4mxWPlEqr3FpFb3i6BozUX26Rl7KyvVXXRe8FN2vdre7 6s27g+xWZ3ZOFFZiKc5INNRiLipOBAC3ScaSAQMAAA==
Archived-At: <>
Cc:, "<>" <>,
Subject: Re: [secdir] Secdir review of draft-ietf-kitten-aes-cts-hmac-sha2-10
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 18:27:13 -0000

[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

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

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

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.

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

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

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

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

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