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

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 2 Mar 2022 16:03:17 +0000

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-masked]
>>>> https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 3 Mar 2022 09:12:45 -0800

Hi -

> 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

---

From: Kenneth Vaughn <[email-masked]>
Date: Thu, 3 Mar 2022 12:01:53 -0600

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-masked]
www.trevilon.com

> On Mar 3, 2022, at 11:12 AM, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
>