Re: [lamps] Paul Wouters' No Objection on draft-ietf-lamps-5g-nftypes-08: (with COMMENT)

Russ Housley <housley@vigilsec.com> Sat, 03 December 2022 18:48 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC02C1524AE; Sat, 3 Dec 2022 10:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd-RroaCssPH; Sat, 3 Dec 2022 10:48:01 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5745C14F75F; Sat, 3 Dec 2022 10:48:01 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id EA063DFC89; Sat, 3 Dec 2022 13:48:00 -0500 (EST)
Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id BA26EDFA48; Sat, 3 Dec 2022 13:48:00 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <FCB8228D-1461-44CE-913E-491ED02C1BFA@aiven.io>
Date: Sat, 03 Dec 2022 13:48:00 -0500
Cc: IESG <iesg@ietf.org>, draft-ietf-lamps-5g-nftypes@ietf.org, LAMPS Chairs <lamps-chairs@ietf.org>, LAMPS <spasm@ietf.org>, tim.hollebeek@digicert.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <28419D97-71AA-4B47-8B46-613808F84162@vigilsec.com>
References: <3F1BCE66-AAB4-49EC-9481-215008A58F05@vigilsec.com> <FCB8228D-1461-44CE-913E-491ED02C1BFA@aiven.io>
To: Paul Wouters <paul.wouters@aiven.io>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.10 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/AyYV4qsdZISyM8Ji-n4wyklX5HE>
Subject: Re: [lamps] Paul Wouters' No Objection on draft-ietf-lamps-5g-nftypes-08: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2022 18:48:06 -0000

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Thanks for the document.
>>> 
>>> I just have one question.
>>> 
>>> This extension MUST NOT be marked critical.
>>> 
>>> Why not? One can argue this is greenField deployment but it would be a rather big one :P
>>> 
>>>> From what I am reading, this extension is required for 5g, so why not mark it critical if
>>> the extension is not understood?
>> 
>> TLS is being used for authentication, integrity, and confidentiality within the 5G core, so I do not think we can ensure  that this is a greenField deployment.
> 
> I think I was unclear.  The document says these NFtypes are required for 5G. So they MUST be present. If that is the case, a system that doesn’t understand NFtypes fails. This type of extension understanding requirement is usually signalled with marking it critical, so I didn’t understand why this critical marking was a MUST NOT.

Paul, the document does not say that NFTypes are required for all certificates in 5G.  In fact the Release 17 documents from 3GPP do not require this extension.  It was not specified at the time those documents were written.  It is expected that future 5G documents will make use of this extension, but marking it critical would hinder transition from Release 17 to those future releases/stages.

Russ