Re: [IAB] Comments from the IAB on NIST SP 800-90A Proceeding

Russ Housley <housley@vigilsec.com> Thu, 24 October 2013 16:32 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C568C11E81C5 for <ietf@ietfa.amsl.com>; Thu, 24 Oct 2013 09:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.179
X-Spam-Level:
X-Spam-Status: No, score=-100.179 tagged_above=-999 required=5 tests=[AWL=-2.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_AVOID=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhtaxNfbjrqp for <ietf@ietfa.amsl.com>; Thu, 24 Oct 2013 09:32:45 -0700 (PDT)
Received: from odin.smetech.net (unknown [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 050C411E81B2 for <ietf@ietf.org>; Thu, 24 Oct 2013 09:32:41 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6D22D9A4169; Thu, 24 Oct 2013 12:32:30 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id YV7bFqw3T1Ua; Thu, 24 Oct 2013 12:32:09 -0400 (EDT)
Received: from [192.168.2.107] (pool-71-191-197-233.washdc.fios.verizon.net [71.191.197.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2F0449A416F; Thu, 24 Oct 2013 12:32:09 -0400 (EDT)
Subject: Re: [IAB] Comments from the IAB on NIST SP 800-90A Proceeding
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <5268CE6A.3030904@gmx.net>
Date: Thu, 24 Oct 2013 12:31:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D085255C-3675-48B4-BE08-E3D224FBBC72@vigilsec.com>
References: <CAOW+2dukS-Zye-T9NcWnstSmydpG4YaT6bW_CKh-KYhJQfasUA@mail.gmail.com> <02364CCE-9122-4EC0-A2D8-16C3FE16245F@isoc.org> <0C7687D7-CFAF-4122-950D-13DCAC6A3598@iab.org> <CADnDZ8_Vor0ksG1Q+PU0QH1O-ViDbziBqNh72bw4eL1T2LCrKA@mail.gmail.com> <CABSMSPX8LcVNEfQc08Yx_73pL3DRfN_Sj09v9OdbOex7=4NNXw@mail.gmail.com> <5268CE6A.3030904@gmx.net>
To: IETF <ietf@ietf.org>
X-Mailer: Apple Mail (2.1085)
Cc: IAB <iab@iab.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2013 16:32:50 -0000

>>> depend on NIST standard process and development? Is the statement talking
>>> about all IETF security standards?
> 
> 
> As I tried to explain in http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-00 the IETF is currently not in the business of developing cryptographic primitives. This work is done outside the IETF (to a large extend).
> 
> Of course, our security protocols have to use cryptographic primitives and there is the question where do these come from.
> 
> It turns out that there are not that many organizations in the world who have the necessary level of expertise. NIST is one of them.

Indeed.

Some IETF standards normatively reference NIST cryptographic standards, and many of them are the mandatory to implement algorithm.  So, these IETF standards do depend on the NIST standards, and indirectly on the process by which the NIST standards were developed.

The IETF has developed it own cryptographic mechanisms when there has been a void.  RFC 3217 is one example.  When that work was done by the S/MIME WG, the group went to great lengths to get cryptographers to participate.  This is not the preferred approach, but sometimes there is a void that needs to be filled.

Russ