Re: [secdir] secdir review of draft-housley-suite-b-to-historic-04

Russ Housley <housley@vigilsec.com> Tue, 24 April 2018 15:51 UTC

Return-Path: <housley@vigilsec.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 44B4912E8CE for <secdir@ietfa.amsl.com>; Tue, 24 Apr 2018 08:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pS3e-_u0Zi7v for <secdir@ietfa.amsl.com>; Tue, 24 Apr 2018 08:51:49 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF0C12D779 for <secdir@ietf.org>; Tue, 24 Apr 2018 08:51:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 75588300A0E for <secdir@ietf.org>; Tue, 24 Apr 2018 11:51:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CZb4pxqvGLtO for <secdir@ietf.org>; Tue, 24 Apr 2018 11:51:45 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 90BE6300435; Tue, 24 Apr 2018 11:51:45 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <alpine.LRH.2.21.1804241056020.17777@bofh.nohats.ca>
Date: Tue, 24 Apr 2018 11:51:46 -0400
Cc: IESG <iesg@ietf.org>, IETF SecDir <secdir@ietf.org>, draft-housley-suite-b-to-historic.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C83CCC3-063E-416D-BB68-70E15C726C96@vigilsec.com>
References: <ldv36zl5kjd.fsf@ubuntu-1gb-nyc1-01.localdomain> <alpine.LRH.2.21.1804241056020.17777@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>, Taylor Yu <tlyu@mit.edu>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ZkJH8C85MjIHo1sIgNbN9JZ1hHg>
Subject: Re: [secdir] secdir review of draft-housley-suite-b-to-historic-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 24 Apr 2018 15:51:51 -0000

> On Apr 24, 2018, at 11:08 AM, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Tue, 24 Apr 2018, Taylor Yu wrote:
> 
>> "7.  Security Considerations
>> 
>>  The CNSA Suite includes algorithms using the larger key sizes that
>>  are included in Suite B.  There are no interoperability or security
>>  concerns raised by reclassifying the Suite-B-related RFCs to Historic
>>  Status."
> 
> This text is interesting as I see two statements by the US government
> on the CNSA Suite.
> 
> The first one is at:
> 
> https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
> 
> Which claims the CNSA Suite is not published yet, but there is a
> transition set of algorithms to use.
> 
> The second one is at:
> 
> https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm
> 
> Which lists the same algorithms, but no longer calls these a transition
> list but the actual CNSA Suite.
> 
> Regardless, since I think the IETF should not be advertising a single
> governments crypto standards, I think this document would be better of
> not mentioning CNSA in Section 7 at all. We shouldn't have stamped Suite B
> in the IETF either, but we were young and naive at the time. So let's
> not stamp CNSA as a "successor" in any kind of way. The only thing this
> document should do is move Suite B to Historic.
> 
> I would suggest something like this for Section 7:
> 
> 	The algorithms and key sizes from Suite B, where these algorithms
> 	and key sizes were published by the IETF, have been obsoleted or
> 	updated by new and more secure algorithms and key sizes. Please
> 	see the respective IANA registries and RFC updates for the
> 	specific algorithm usage within their specific protocols.

I think that last sentence of the existing Security Considerations should remain:

   ... There are no interoperability or security
   concerns raised by reclassifying the Suite-B-related RFCs to Historic
   Status.

In fact, I think it should be said first.

> I'm fine with mentioning CNSA in Section 2.

Good.  I think it is useful information.

Russ