Re: [Cfrg] On "non-NIST"

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 28 February 2015 17:40 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73A21A7007 for <cfrg@ietfa.amsl.com>; Sat, 28 Feb 2015 09:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 0DV68UIkrf-2 for <cfrg@ietfa.amsl.com>; Sat, 28 Feb 2015 09:40:45 -0800 (PST)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFBA1A1BF5 for <cfrg@irtf.org>; Sat, 28 Feb 2015 09:40:44 -0800 (PST)
Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t1SHede0030787 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2015 10:40:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CACsn0ckHyRiLBiRe9Vg4TJMUg-+c8vbB2e-QKuHbuZ_NiqC2UA@mail.gmail.com>
Date: Sat, 28 Feb 2015 09:40:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B56D6A89-A111-40BB-9AE2-F3EEF512262A@vpnc.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF91123@uxcn10-5.UoA.auckland.ac.nz> <BE305B0B-80D2-48C6-ACE6-6F6544A04D69@vpnc.org> <CACsn0ckHyRiLBiRe9Vg4TJMUg-+c8vbB2e-QKuHbuZ_NiqC2UA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/KormsWEdjaaYCVIgL3vMENSFcGc>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [Cfrg] On "non-NIST"
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Feb 2015 17:40:45 -0000

On Feb 28, 2015, at 9:17 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> On Sat, Feb 28, 2015 at 7:41 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> On Feb 28, 2015, at 12:59 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>>> 
>>> Paul Hoffman <paul.hoffman@vpnc.org> writes:
>>> 
>>>> The term "non-NIST" is predictive, and the crypto community kinda sucks at
>>>> predictions. We have no idea what NIST will do in the future if a bunch of
>>>> IETF WGs adopt specific elliptic curves that are not P256/P384.
>>> 
>>> Why is NIST seen as the ultimate arbiter of what's appropriate though?
>> 
>> Not "the", but "an". The reason is that NIST controls what can and cannot be given a FIPS-140 certification, and that certification is considered important both by companies who want to sell to the US Govt and companies that use their certification as a statement that "we did it right". If you make an HSM that uses an algorithm not allowed by NIST, you cannot get it certified in the CMVP regime. Thus, when NIST is slow to keep up with the best practices adopted by the community, it becomes a roadblock to deploying better crypto.
> 
> This is factually untrue: CMVP certified modules are permitted to
> implement other algorithms: they just can't be in FIPS mode when those
> are used.

That sentence assumes a few things: an HSM that has multiple signing algorithms *and* a lab that would allow non-certified signing algorithms to be within the crypto module that gets the Level 2+ certification *and* the CMVP program allowing the lab's evaluations. To the best of my knowledge, this has never happened. (Disclaimer: NIST once paid me to become an expert on the CMVP process and how crypto vendors and labs dealt with it, but I have not kept my day-to-day knowledge of it up to date in recent years.)

What you describe is quite common in devices that get Level 1 certifications, but it is not clear that something that normally is expected to have a Level 2+ validation, specifically like HSMs, would be able to do so.

--Paul Hoffman