I agree, an update can be delayed until we actually need to add support for additional hash algorithms. (And some of the concerns by the TLS folks may disappear once the usage of TLS 1.2 further declines.)
/js On Mon, Feb 28, 2022 at 11:04:15AM -0800, Randy Presuhn wrote: > Hi - > > On 2022-02-28 10:45 AM, 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. > > Perhaps, though that would have brought its own coordination problems. > > > 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). > > I agree with your analysis that, while a bit of a stretch, an update > to the DESCRIPTION seems like the right thing to do to placate the > TLS folks, since it would not affect the bits on the wire nor, as far > as I can see, what implementations do internally. My questions were > based in my skepticism with regard to to the stance that *any* MIB > module changes would really be technically (rather than politically) > necessary. > > Randy > > > /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 > > > 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/> _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
