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 protected] www.trevilon.com > On Jan 18, 2022, at 4:41 PM, Jürgen Schönwälder > <[email protected]> wrote: > > On Tue, Jan 18, 2022 at 08:00:12PM +0000, Joe Clarke (jclarke) wrote: >> >> >> 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? >> > > 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 > > -- > 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/> >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
