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)

[Jürgen Schönwälder <[e-mail]>]

Ken,

note sure what "all these references" are. I am now looking at Section
15 of RFC 8447 and it states that the values in the TLS HashAlgorithm
registry are only applicable to version of (D)TLS protocol versions
prior to 1.3. This does not necessarily imply that we can't continue
to use them for the fingerprint algorithm. Hence, this might have all
been a false alarm... Perhaps we need to let IANA know somehow that
there are non (D)TLS specifications depending on the registry values
so that they can take a note in case people in the future want to
deprecate the registry.

/js

On Thu, Dec 09, 2021 at 08:54:36AM -0600, Kenneth Vaughn wrote:
> Juergen,
> 
> It seems to me that all of these references argue for asking IANA to maintain the one-octet identifiers for the hashing algorithms (i.e., including the addition of new identifiers as new algorithms are developed), even after TLS 1.2 fades from use. That will allow the fingerprint algorithm to remain unchanged in all of these scenarios and greatly simplifies our update effort.
> 
> Regards,
> Ken Vaughn
> 
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> [phone]
> [phone] cell
> [e-mail]
> www.trevilon.com
> 
> > On Nov 19, 2021, at 1:40 PM, Jürgen Schönwälder <[e-mail]> 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).
> > 
> > /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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/opsawg
> >> 
> >> -- 
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>
> > 
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>