Yes, there are plans to add new additions. If there is a new, paralell registry for the sole use of this SNMP transport, then there should not be a chance for TLS implementors to be confused.
Admittedly, this isn't completely optimal, but in light of other options, which would involve larger MIB changes, it seems like a viable path that does have some longevity to it. Joe On 3/1/22 00:40, Randy Presuhn wrote: > Hi - > > Wait... are there or are there not any plans for additions to the > registry? If there are no plans for additions, the argument about > confused TLS implementors seems hypothetical. If there are plans for > additions, is it envisioned that any of the existing algorithms will > eventually be in some sense deprecated? What terrible things will > happen if some confused maintenance engineer manages to bolt one of > these new algorithms onto their TLS 1.2 implementation, presumably > despite advice to the contrary in its registration? > > Will creating a new registry really prevent these confused maintenance > engineers from making the same mistake? > > Randy > > On 2022-02-28 2:58 PM, Joe Clarke (jclarke) wrote: >> Maybe "fear" is too string a word, but the sentiment was that it gave >> mixed messages to start adding new values to that table (which they feel >> is static at this point) and could lead to confusion with implementors. >> >> Given that it seemed to me _this_ change in DESCRIPTION could be >> considered semantically the same, I thought it wouldn't warrant a new >> object and could be much smaller than a whole MIB rewrite. I wanted Ken >> to socialize that here. >> >> Joe >> >> On 2/28/22 13:45, Jürgen Schönwälder wrote: >>> Randy, >>> >>> I assume it is fear of all of that, whether this is justified or not >>> can be debated. Frankly, we used a protocol registry because it was >>> handy and we likely did not like a proliferation of registries. In >>> hindsight, we would have been better off creating our own. >>> >>> Does it make sense to republish an entire MIB module to just change >>> the registry location? Ideally this would not be required and we would >>> simply publish a document updating RFC 6353 and defining the new >>> registry (and even more so given that no registry content change is >>> envisioned). >>> >>> /js >>> >>> On Mon, Feb 28, 2022 at 10:24:53AM -0800, Randy Presuhn wrote: >>>> Hi - >>>> >>>> On 2022-02-28 6:28 AM, Kenneth Vaughn wrote: >>>>> To OPSAWG, especially MIB doctors and SNMP-experts: >>>>> >>>>> We have contacted the TLS community about potentially allowing for the >>>>> continued use and maintenance of the IANA TLS HashAlgorithm Registry >>>>> (RFC 5246) in the update to RFC 6353 so that we do not have to redefine >>>>> its fingerprint algorithm. The TLS community expressed a valid concern >>>>> that if the registry is maintained by adding new values, it would imply >>>>> that those new values could be used within TLS 1.2; thus our proposal to >>>>> continue to reference the existing table was not accepted. >>>> I don't understand the fear here. Are they worried that: >>>> >>>> - someone would misconstrue additions to the IANA TLS HashAlgorithm >>>> Registry as somehow *requiring* TLS 1.2 implementations to be >>>> updated, even though they've been "designated obsolete"? >>>> >>>> - that despite TLS 1.2 having been "designated obsolete", folks >>>> maintaining those implementations would take it upon themselves >>>> to add support for later additions to the IANA TLS HashAlgorithm >>>> Registry? >>>> >>>> - that there might be a proliferation of TLS 1.2 deployments that >>>> attempt to use the additions to the IANA TLS HashAlgorithm >>>> Registry, despite TLS 1.2 having been "designated obsolete"? >>>> >>>> - that the possibility of adding these algorithms might somehow >>>> prolong the lifetime of existing TLS 1.2 deployments or even >>>> lead to new ones, despite it having been "designated obsolete"? >>>> >>>> - something else? >>>> >>>> Randy >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
