We made the mistake by simply reusing the TLS hash algorithm for a different purpose. We now factor things out by having a separate registry for the hashing algorithms used to create certficate fingerprints. But why would we now tie this back to TLS hashing algorithms? In modern TLS, I think they only register entire ciphersuites, do we really expect them to go an register any new hash algorithm that comes along into the registry of hash algorithms for producing certificate fingerprints?
I understand the "we are too lazy to do this" argument but then still I would expect that if a new hash is being implemented for certificate fingerprinting, someone would find the energy to register it. /js On Thu, May 05, 2022 at 11:15:46AM -0500, Kenneth Vaughn wrote: > > There is no definition of TLSTMv1.3 nor do we version MIB modules > Agreed, This is old text that I missed from when this was intended to be a > replacement to RFC 6353 rather than an update. I think it is best to just > delete the sentence so the paragraph would now read "[RFC6353] stated that > TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. [RFC8996] > prohibits the use of (D)TLS versions prior to version 1.2." While the > statement is not technically required as it is stated elsewhere, I believe > there was a comment during IETF 113 that we should be explicit about this. > > > In addition, a new entry > > MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a > > new hash algorithm is approved for any version of TLS or DTLS. > I guess there are two issues here: 1) What do we want and 2) What wording is > used for IANA instructions > > In the first case, while I accept that there is not a strict technical > requirement to implement every hash algorithm adopted by TLS, I am hard > pressed to think of why we would ever not want to support one (or what > practical harm it would cause). If we don't make the cross-assignment > automatic, it seems as if it would be incumbent upon the WG to explicitly > make requests every time a new hash algorithm came along. That seems to be > extra bureaucratic work for OPSAWG and it seems as if it would be easier to > make it a part of the IANA process. So the proposal is that it should be > automatic (which is in agreement with a comment made at the IETF 113 meeting) > > If we agree that it should be automatic, then the second issue is how do we > state this. I am happy to revise the wording as appropriate; I certainly am > not an expert in writing those statements. > > If we don't want it to be automatic, then perhaps we need to reach consensus > on how new entries will be added. > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-936-647-1910 > +1-571-331-5670 cell > kvau...@trevilon.com > www.trevilon.com > > > On May 5, 2022, at 10:32 AM, Jürgen Schönwälder > > <j.schoenwael...@jacobs-university.de> wrote: > > > > Before I go and check the details... > > > > [...] TLSTMv1.3 MUST only be used with > > (D)TLS version 1.2 and later. > > > > What does this MUST tell me? There is no definition of TLSTMv1.3 nor > > do we version MIB modules. I understand the intention of the statement > > but we need to be more careful about the wording. > > > > And what about this: > > > > [...] In addition, a new entry > > MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a > > new hash algorithm is approved for any version of TLS or DTLS. > > > > Why would that be a MUST? The SnmpTLSFingerprint is used by the MIB > > module to hash certificates and as such this hashing has nothing to do > > with any TLS internal use of hash algorithms. The reuse of the TLS > > hash registry back then was a matter of convenience, not a matter of > > having a strong binding to the TLS internal usage of hash algorithms. > > > > /js > > > > On Thu, May 05, 2022 at 10:09:45AM -0500, Kenneth Vaughn wrote: > >> I have uploaded a new version of the "Updates to the TLS Transport Model > >> for SNMP". This version includes the following changes: > >> Changed the name of the registry to the SNMP-TLSTM registry > >> Updated reference to DTLS 1.3 to reflect the publication of RFC 9147 > >> Clarified the first paragraph of Conventions to indicate that references > >> to TLS, DTLS, (D)TLS, and TLSTM are version neutral except where specific > >> versions need to be cited. > >> Changed "SNMPv3" to "SNMP" in several locations where the specific version > >> reference was unnecessary with our convention statement > >> Indicated that Additional Rules for TLS 1.3 "may additionally apply to > >> future versions of TLS" > >> The document has been through several review cycles and has also been > >> vetted by the TLS WG. At this point, changes are primarily editorial and I > >> believe it is stable enough to proceed to the next step of the approval > >> process. > >> > >> Regards, > >> Ken Vaughn > >> > >> Trevilon LLC > >> 6606 FM 1488 RD #148-503 > >> Magnolia, TX 77354 > >> +1-936-647-1910 > >> +1-571-331-5670 cell > >> kvau...@trevilon.com > >> www.trevilon.com > >> > >>> On May 5, 2022, at 10:07 AM, internet-dra...@ietf.org wrote: > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> This draft is a work item of the Operations and Management Area Working > >>> Group WG of the IETF. > >>> > >>> Title : Updates to the TLS Transport Model for SNMP > >>> Author : Kenneth Vaughn > >>> Filename : draft-ietf-opsawg-tlstm-update-03.txt > >>> Pages : 30 > >>> Date : 2022-05-05 > >>> > >>> Abstract: > >>> This document updates the TLS Transport Model (TLSTM), as defined in > >>> RFC 6353, to reflect changes necessary to support Transport Layer > >>> Security Version 1.3 (TLS 1.3) and Datagram Transport Layer Security > >>> Version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". > >>> This document is compatible with (D)TLS 1.2 and is intended to be > >>> compatible with future versions of SNMP and (D)TLS. > >>> > >>> This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/ > >>> > >>> There is also an HTML version available at: > >>> https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-03.html > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-03 > >>> > >>> > >>> Internet-Drafts are also available by rsync at > >>> rsync.ietf.org::internet-drafts > >>> > >>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> OPSAWG@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsawg > >>> > >> > > > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > > > -- > > 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/> > > > -- 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
