[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
- Re: [secdir] Secdir review of draft-ietf-kitten-a… Watson Ladd
- Re: [secdir] Secdir review of draft-ietf-kitten-a… Benjamin Kaduk
- Re: [secdir] Secdir review Watson Ladd
- Re: [secdir] Secdir review Paul Hoffman
- [secdir] Secdir review Watson Ladd