Subject: [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: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 19 Nov 2021 16:26:50 +0000

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

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 19 Nov 2021 19:57:32 +0100

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:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> 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/>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 19 Nov 2021 20:40:37 +0100

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

---

From: Benoit Claise <[email-masked]>
Date: Sat, 20 Nov 2021 09:05:22 +0000

> 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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 20 Nov 2021 10:24:43 -0500

> perhaps opsawg did have the expertise and could pick this up.

I guess I missed this from IETF111.
I scanned the document briefly, and I don't see that much that requires
*SNMP*-fu, so much as it requires TLS-fu.

I think that the document will get lost in OPSAWG.

Traditionally, WGs do their own MIB modules... so I don't understand why it
is not in TLS.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 29 Nov 2021 15:59:39 +0000

Just wanted to provide a post-US Thanksgiving reminder that this call
for adoption is ongoing and set to close on December 10.

Joe

---

From: <[email-masked]>
Date: Tue, 30 Nov 2021 13:39:14 +0000

Hi all, 

I support adopting this work. 

I think that the document has more chances to make progress in opsawg than tls. I trust the chairs will liaise with the tls wg so that the document is reviewed there as well.  

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG <[email-masked]> De la part de Michael Richardson
> Envoyé : samedi 20 novembre 2021 16:25
> À : [email-masked]
> Objet : 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)
> 
> 
> Traditionally, WGs do their own MIB modules... so I don't understand why
> it is not in TLS.
> 
> --

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.