Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-03-03 Thread Kenneth Vaughn
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-03-03 Thread Randy Presuhn
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,

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-03-02 Thread Joe Clarke (jclarke)
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Randy Presuhn
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Joe Clarke (jclarke)
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Jürgen Schönwälder
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Randy Presuhn
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Jürgen Schönwälder
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Randy Presuhn
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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2022-02-28 Thread Jürgen Schönwälder
If we change the registry but none of the semantics of any existing allocations (i.e., we make a deep copy initially), then I think this is just fine regarding the updating rules (since nothing should of this should affect on the wire interoperability). We should be careful with the wording. The