Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice

Russ Housley <housley@vigilsec.com> Fri, 11 December 2020 16:52 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387F93A0D21 for <last-call@ietfa.amsl.com>; Fri, 11 Dec 2020 08:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 mCB78kb-ZDSS for <last-call@ietfa.amsl.com>; Fri, 11 Dec 2020 08:52:46 -0800 (PST)
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 C10AF3A0964 for <last-call@ietf.org>; Fri, 11 Dec 2020 08:52:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1B4F0300BC1 for <last-call@ietf.org>; Fri, 11 Dec 2020 11:52:44 -0500 (EST)
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 A8SbqJOIM6WE for <last-call@ietf.org>; Fri, 11 Dec 2020 11:52:42 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 48223300AB0; Fri, 11 Dec 2020 11:52:42 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <d64183b5-067b-5f6b-e5c8-0975311f2fbf@si6networks.com>
Date: Fri, 11 Dec 2020 11:52:43 -0500
Cc: Ben Kaduk <kaduk@mit.edu>, last-call@ietf.org, draft-gont-numeric-ids-sec-considerations@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A0B53B2-71D7-4623-90CC-E0E884101C31@vigilsec.com>
References: <160735373732.25981.15176977559155786235@ietfa.amsl.com> <F438198F-34E2-4C9F-A32F-ACD58D9A6734@vigilsec.com> <20201209211455.GZ64351@kduck.mit.edu> <327D2176-1722-4F83-9ED1-205C575D67E6@vigilsec.com> <d64183b5-067b-5f6b-e5c8-0975311f2fbf@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/DZSrVD7ZGTEsXwRF9H0BIvwroeA>
Subject: Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2020 16:52:48 -0000

Fernando:

>>> On Wed, Dec 09, 2020 at 04:09:07PM -0500, Russ Housley wrote:
>>>> I have to comments.
>>>> 
>>>> 1) I do not see this document as a BCP.  Despite the inclusion of the boilerplate, there is not a single MUST in the document.  I have no objection to an Informational RFC.
>>> 
>>> The assumption/expectation was that this would become part of BCP 72 along
>>> with RFC 3552.  Do you think it should be a standalone document, or can you
>>> propose normative language that would make it more appropriate as a BCP?
>> I'd advise an Informational document. 
> 
> FWIW, our intent is to have a BCP document that is part of (i.e., updates) BCP72.  Given that flawed transient identifiers have plagued most IETF protocols we can think of, we believe the topic deserves a BCP.
> 
> 
>> I think an additional section with normative text would be needed or additional normative paragraphs after each of the problem descriptions would be needed.
> 
> Could you please elaborate?

It is not a Best Current Practice if the document does not provide MUST and SHOULD statements for implementers to follow.

The current document provides information for implementers to consider in making their design choices, but it falls short if a BCP in my view.

Russ