Let me add one additional observation: RFC 6353 has been a blueprint for the YANG data model for SNMP configuration defined in RFC 7407. The ietf-x509-cert-to-name module, which is part of RFC 7407, defines a tls-fingerprint, which is also using a 1 octet hashing algorithm identifier. If we expand SNMP's TC, we should also look at the YANG equivalent. I also spotted that the YANG definition is imported by draft-ietf-netconf-https-notif-09.txt, I am not sure whether there are any other imports of this YANG definition (or the SNMP TC).
/js On Fri, Nov 19, 2021 at 07:57:32PM +0100, Jürgen Schönwälder wrote: > Hi, > > any clarifications that are necessary to run SNMP over (D)TLS 1.3 are > worth to work on. Looking at the document, it leaves me a bit puzzled > of what is actually changed. I think all text that is in RFC 6353 and > not modified should be removed from the update (for example, I think > there is no need to republish text concerning USM). For the MIB > module, it would help a lot if the revision clause would detail what > has actually changed instead of just saying "This version updated the > MIB to support (D)TLS 1.3." I like to see concrete text like > > - SnmpTLSFingerprint has been depracted and SnmpTLS13Fingerprint > has been introduced. > > - The snmpTlstmCertToTSNTable has been deprecated and a new > snmpTlstmCertToTSN13Table has been introduced. > > - The snmpTlstmParamsTable has been deprecated and a new > snmpTlstmParams13Table has been introduced > > I find it problematic to embed "13" in the new object names as this > suggests the objects work only for TLS 1.3, which I hope is not the > case, i.e., I hope we do not have do yet another update when (D)TLS > 1.4 comes along in the future - or is the idea we actually do that? I > think there should also be clear guidelines what implementations > should do, implement the new objects and accept also D(TLS) 1.2 > configurations via them or should the new objects only be supported > for D(TLS) 1.3 (and higher?) configurations? > > /js > > PS: There are also some bugs in the MIB module, mpTlstmAddrCount > should be snmpTlstmAddrCount and CONTACT-INFO string is not > terminated. > > On Fri, Nov 19, 2021 at 04:26:50PM +0000, Joe Clarke (jclarke) wrote: > > Hello, WG. Kenneth presented > > https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at IETF112 > > to us, and this was previously presented at SecDispatch at IETF111. The > > feeling there was that this work had merit, but Sec didn't have enough > > SNMP experience to be the owner. At the AD level, the feeling was that > > perhaps opsawg did have the expertise and could pick this up. > > > > Therefore, this serves as a three week call for adoption of this draft. > > The three weeks is being given due to the US holiday next week. There > > has already been some comments regarding scope that have been raised > > on-list, and Kenneth has called out potential courses of action in his > > 112 presentation. > > > > Please respond by December 10, 2021 regarding your thoughts on adopting > > this work as well as comments on the work so far. > > > > Thanks. > > > > Joe > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > -- > Juergen Schoenwaelder 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/> -- Juergen Schoenwaelder 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
