On 11/19/2021 7:40 PM, Jürgen Schönwälder wrote:
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).
https://yangcatalog.org/yang-search/impact_analysis/ietf-x509-cert-to-name@2014-12-10
Just click on the red circles to find out the related drafts.
Note: Just opened a bug on this one,
https://github.com/YangCatalog/sdo_analysis/issues/103
Regards, Benoit
/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/>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
