If we were adopting the TLS 1.3 registry, that would be a possibility - but we aren't. We are proposing to create a new registry that will parallel the existing registry specifically for TLSTM (or at least specific to standards that reference a range of TLS versions). As a result, we would not have to update this RFC again for future TLS versions (for this particular issue).
Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-936-647-1910 +1-571-331-5670 cell [email protected] www.trevilon.com > On Mar 3, 2022, at 11:12 AM, Randy Presuhn > <[email protected]> wrote: > > Hi - > > On 2022-03-02 8:03 AM, Joe Clarke (jclarke) wrote: >> 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. > > So... If I understand this "longevity" plan correctly, when TLS 1.4 > comes along we'll need to create yet another registry to prevent > confused TLS 1.3 (as well as TLS 1.2) maintenance engineers from adding > inappropriate algorithms? > > Randy > >> 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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
