[secdir] Secdir review

Watson Ladd <watsonbladd@gmail.com> Fri, 08 July 2016 02:56 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8112B01C; Thu, 7 Jul 2016 19:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq7edB_brUup; Thu, 7 Jul 2016 19:56:41 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4048912B00D; Thu, 7 Jul 2016 19:56:41 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id f7so29529740vkb.3; Thu, 07 Jul 2016 19:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=vgHEgm/XxHa5yEU+4uWnuUqbUhDF69xVXbZNXs6WFPI=; b=lliooCLLwm4rBw/pqD9xGX6WrpDCZEx7vjq4d5vFvR6mRGdtAtGRzz4Z++BsWixcpW QYBoVXJdm2GPipbNI6GVNInwfR1HV/5MkzJ2MyneOYOtiDtjQXs0JU9FsZYVrf2kOCFl qqdu/iQ2xrmvcn/IfXXsp8nI7eZ3z9oWgIqzLHQ5syTHLpDvwtV7Jvc+18vKxbn9JFsR SBmhiqKNEUz8HLH/8EvdIgu0peQC42Z7wbKlhiXC8ESiJlWQLiAq1RwBPoOZLCAtlbtV LacdQU5MQk5vqHUoS7WXIIW+W0Yzs4lX5pguyVAQmYy7ioqmP1VEvSIud4n0EH63+vln wSPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vgHEgm/XxHa5yEU+4uWnuUqbUhDF69xVXbZNXs6WFPI=; b=TKecv9O8X9Unt/wgx+uy0iKxhrUnA6WkCkBmU6a+5J5t4Xw5Tj6IYMFYfqMCjnleOf aqKvn1H1+IDpC9BFCLc0uDHquKR9VgxwLFYGXAujMOd6+NDXUvfx5md6+nfJo677X+bq nEP01B06chubKyGuAoX2/mfvJzk9V6gRPDqTSYzYyanUChPfnUjzOqh344wQkYpc6Npx IJxCy15OYI4+IUOVKT4qLWQgg8EhkFvno/vqSrEsuVZR2ylBSL2yqbsvMiSFpL/LjuDu Pbt65wZOrl+F/kVED+yIYau8KrOKm5O/sXkba1H15ug/hGLtgCr4otOxz/YDKA1V+8qM Mz7A==
X-Gm-Message-State: ALyK8tJbJeVnGEJA6U5VnkIxjTUfIj+G0dnOWgdgIWh+5qIc7Civ7SIz4z8rm4urSBDEWUF6BGxrD+58UEna5w==
X-Received: by 10.159.33.201 with SMTP id 67mr1763358uac.90.1467946600260; Thu, 07 Jul 2016 19:56:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.39.194 with HTTP; Thu, 7 Jul 2016 19:56:39 -0700 (PDT)
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 07 Jul 2016 19:56:39 -0700
Message-ID: <CACsn0cnJeyTB2fAoEMqxS2OG76T42APFvcdMmb=yOP7DuLuD0g@mail.gmail.com>
To: draft-ietf-kitten-aes-cts-hmac-sha2.all@tools.ietf.org, "<iesg@ietf.org>" <iesg@ietf.org>, secdir@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DTjTpy3irdkBiVWZ-VONfrVgfWo>
Subject: [secdir] Secdir review
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 02:56:43 -0000

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