On 1/5/22 09:39, Kenneth Vaughn wrote: 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: 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? a. Support and enablement mandatory b. Support mandatory; enablement silent; use not recommended (RFC 6353 for USM) My opinion (as a contributor) would be this option (b). Joe
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
