Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

Kenneth Vaughn <kvaughn@trevilon.com> Wed, 05 January 2022 14:39 UTC

Return-Path: <kvaughn@trevilon.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48913A0A8C for <opsawg@ietfa.amsl.com>; Wed, 5 Jan 2022 06:39:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=trevilon.com
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 Xql66BwNr6Nj for <opsawg@ietfa.amsl.com>; Wed, 5 Jan 2022 06:39:37 -0800 (PST)
Received: from tre.trevilon.com (tre.trevilon.com [198.57.226.42]) (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 E2C183A0A8E for <opsawg@ietf.org>; Wed, 5 Jan 2022 06:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bTMUCDHW2Xn9WPzU/hPr6CMRN/LPylass9mSbz0igUA=; b=n5qbbY7wVKr/MmMCanVVJYXc0R 2bU2KOov8lXpBrHRWWPJpilD03RZqpnG89Xt0f3h70oeKZXTYMeUV6Zammk8K5KzBuzRtu7FR/tDN IDaJC72YMJwNjjxkz6b/WpK2B;
Received: from mobile-166-172-57-224.mycingular.net ([166.172.57.224]:8344 helo=smtpclient.apple) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <kvaughn@trevilon.com>) id 1n57Rt-00064g-F9; Wed, 05 Jan 2022 14:39:33 +0000
From: Kenneth Vaughn <kvaughn@trevilon.com>
Message-Id: <9E5FF73A-0A84-4083-A672-AE3DD254EA7A@trevilon.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_51EF244C-13DB-4238-90F8-A86C7FF2C287"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Date: Wed, 05 Jan 2022 08:39:30 -0600
In-Reply-To: <AM7PR07MB624852B472EAFAF009EF2DE9A0789@AM7PR07MB6248.eurprd07.prod.outlook.com>
Cc: "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, Wes Hardaker <wjhns1@hardakers.net>
To: tom petch <ietfc@btconnect.com>
References: <BL1PR11MB53687965E7A0BD7C0F090073B89C9@BL1PR11MB5368.namprd11.prod.outlook.com> <BN9PR11MB537169D7B4D554A3B3C9796CB8769@BN9PR11MB5371.namprd11.prod.outlook.com> <AM7PR07MB624852B472EAFAF009EF2DE9A0789@AM7PR07MB6248.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - tre.trevilon.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - trevilon.com
X-Get-Message-Sender-Via: tre.trevilon.com: authenticated_id: kvaughn@trevilon.com
X-Authenticated-Sender: tre.trevilon.com: kvaughn@trevilon.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/bVIVbO__CvnEH2UrovPi3vgi4o8>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2022 14:39:42 -0000

Tom, Joe, Wes, et al:

I propose that we address the overarching questions first as they potentially affect the entire scope of the draft. Namely:

Can we can continue to use  <> <>https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18 <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18> for the TLSHashAlgorithm identifier?  Doing so would greatly simplify the update and would eliminate any revision to the SNMP-TLS-TM-MIB.  I believe Joe Clarke is taking the lead to check with the registry experts to see if this can continue to be used. If so, I propose that the next I-D be changed to offer an update to RFC 6353 (rather than a new or replacement RFC). As such, the MIB would be removed, which would shorten the I-D to just a few pages.
RFC 8996 (BCP 195) updated RFC 6353 with a prohibition on using (D)TLS versions prior to 1.2. What is the status of an IETF BCP? In other words, can we reference a Best Current Practice or do we restate the requirements (i.e, is a BCP considered normative text – or is it considered to be a lower precedence since it was approved through a shortened process?). I would think that a BCP is relatively informal and that we would want to formalize the rules in our document.
RFC 6353 indicated that it was "NOT RECOMMENDED" to use a non-transport-aware security model, including USM and previous versions of SNMP. However, support for USM remained a requirement (inherited from STD 62) and other comments were included regarding implementations that supported previous versions of SNMP. Given that a system is only as secure as its weakest link, what should our position be on the use and support of USM and previous versions of SNMP?
a.     Support and enablement mandatory

b.     Support mandatory; enablement silent; use not recommended (RFC 6353 for USM)

c.     Support mandatory; ability to disable mandatory

d.     Support optional/silent; use not recommended (RFC 6353 for old SNMP versions)

e.   Support optional/silent; ability to disable, if supported, mandatory

f.      Support prohibited

Answers to the above should provide a good amount of direction to the effort; if we are successful in having IANA maintain the one-octet identifier, most of the other comments suggested by Tom will be rendered moot by removing the MIB. The others are largely editorial and can be addressed once we have the other questions answered.
 
Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
kvaughn@trevilon.com
www.trevilon.com

>