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)

From: Kenneth Vaughn <[email-masked]>
Date: Wed, 5 Jan 2022 08:39:30 -0600

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
[email-masked]
www.trevilon.com

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 5 Jan 2022 16:04:38 +0100

USM is a part of STD62 and I do not think it is the job of an update
of RFC 6353 to make any changes concerning STD62 and the status of
USM. SNMP RFCs usually talk about what is mandatory to implement (to
guarantee some level of interoperability), they usually are silent
about enablement (whatever that means) and about usage policies.

I believe the focus of an update should be on the technical aspects
necessary to clarify to use SNMP over (D)TLS 1.3 - focus on the
mechanisms, staying away from any policies.

/js

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: tom petch <[email-masked]>
Date: Wed, 5 Jan 2022 17:11:57 +0000

From: Jürgen Schönwälder <[email-masked]>
Sent: 05 January 2022 15:04

<tp>

I agree.

A BCP is a formal document with almost the same status as a Proposed Standard as described in RFC2026 (ignoring the many updates thereto).

Separately, an update to a Standard should go through the standards process which did not happen with the deprecation of older versions of (D)TLS.  I flagged this when the deprecation was being reviewed but got no response.  I suspect that the IESG found it too complicated to contemplate, although it is not without precedent.

Possibly this I-D could become part of STD062 in years to come but I am doubtful.

Tom Petch

/js

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 5 Jan 2022 13:38:32 -0800

Hi -

> mechanisms, staying away from any policies.

Total agreement, particularly since existing mechanisms (e.g.
VACM configuration) can effectively de-fang (if not totally
"disable") USM.  SecurityModel is part of the tuple that defines
a group within VACM.  If a particular SecurityModel is not present
within the VACM vacmSecurityToGroupTable, no protocol operations
(incoming or outgoing) will be allowed for that model.

Not as air-tight as, say, not even listening on a particular port,
but such deployment decisions are, I think, outside our scope.

Randy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 18 Jan 2022 20:00:12 +0000

On 1/5/22 09:39, Kenneth Vaughn wrote:
Tom, Joe, Wes, et al:

  1.  Can we can continue to use 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.

On this topic, I reached out to the tls-reg-review experts list on this registry.  The consensus there is that the TLSHashAlgorithm registry is for TLS 1.2 and for hashes supported by TLS < 1.3.  In other words, if new hashes were to be added here, they would imply support by TLS < 1.3.  This is obviously not desired.

The suggestion was to connect with tls@ to get additional suggestions on how to move forward.

  1.  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.

The BCP is very similar to a standards-track document, and you can reference it.  I also think you can restate the requirement not to use TLS < 1.2.

  1.  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?

My opinion (as a contributor) would be this option (b).

Joe

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 18 Jan 2022 23:41:42 +0100

>   1.  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 (inh…

I think there is some confusion here. RFC 6353 says:

   Using a non-transport-aware Security Model with a secure Transport
   Model is NOT RECOMMENDED.

The text does _not_ say that USM is NOT RECOMMENDED. It says that the
combination USM/(D)TLS is not recommended, instead TSM/(D)TLS should
be used (with TSM defined in RFC5591). RFC 6353 does not say anything
concerning the usage of STD 62. The scope of RFC 6353 is the transport
of SNMP messages over DTLS/TLS - and nothing else.

One of the big challenges back in the SNMPv3 days was to get
modularity right and from this perspective it feels very wrong if a
secure transport specification provides recommendations about the
usage of something entirely unrelated to the secure transport
specification. If people want to deprecate or retire USM, then this
requires a separate document that changes STD 62.

/js

---

From: Kenneth Vaughn <[email-masked]>
Date: Wed, 19 Jan 2022 18:31:07 -0600

There seems to be consensus that the update should retain the RFC 6353 position regarding USM. I will make sure the next draft reflects that decision.

Regards,
Ken Vaughn

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

> On Jan 18, 2022, at 4:41 PM, Jürgen Schönwälder <[email-masked]> wrote:
>