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 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
kvau...@trevilon.com
www.trevilon.com

> On Mar 3, 2022, at 11:12 AM, Randy Presuhn 
>  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

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, 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___
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

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 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
 OPSAWG@ietf.org
 https://www.ietf.org/mailman/listinfo/opsawg
> ___
> 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

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 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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 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
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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 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 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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 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

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 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
> 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 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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 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

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 hash algorithm is used for
calculating a fingerprint of some data, it is not really tied to the
mechanisms of specific security protocols (or specific versions of
security protocols).

My personal observation is that sharing IANA registries has proven to
be complicated and it may thus be best to create a rather specific
registry for exactly this use case. Yes, this may require to have
multiple registrations if new hash algorithms come along (rare) but it
avoids problems of (unwanted) side effects if registries are used in
multiple different contexts.

/js

On Mon, Feb 28, 2022 at 08:28:21AM -0600, 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. 
> 
> We now have two potential options as follows:
> 1. Deprecate and replace the existing fingerprint algorithm with a new one. 
> The fingerprint algorithm is used in the index of most of the tables within 
> the RFC 6353 MIB; as a result, deprecating the fingerprint algorithm requires 
> deprecating the assocaited tables; in practice, this results in redefining 
> the entire MIB in RFC 6353.
> 
> 2. Revise the DESCRIPTION clause of SnmpTLSFingerprint to refer to a new, 
> parallel HashAlgorithm Registry. Specifically, we would replace the second 
> paragraph of its DESCRIPTION clause, which currently reads: 
> 
> > An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm 
> > identifier followed by the fingerprint value.  The octet value encoded is 
> > taken from the IANA TLS HashAlgorithm Registry (RFC 5246).  The remaining 
> > octets are filled using the results of the hashing algorithm.
> 
>
> To something like the following:
> 
> > An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm 
> > identifier followed by the fingerprint value.  The octet value encoded is 
> > based on the IANA TLS HashAlgorithm Registry (RFC 5246), However, this 
> > registry is only applicable to (D)TLS protocol versions prior to 1.3, which 
> > are now designated as "obsolete" and are not expected to ever support 
> > additional values. To allow the fingerprint algorithm to support additional 
> > hashing algorithms that might be used by later versions of (D)TLS, the 
> > octet value encoded is taken from IANA SnmpTLSFingerprintAlgorithm 
> > Registry, The initial values within this registry are identical to the 
> > values in the TLS HashAlgorithm registry but can be extended to support new 
> > hashing algorithms as needed.
> 
> 
> While option 2 greatly simplifies the update, the question is whether this 
> can be considered a valid revision to the MIB. Per RFC 2578 Section 10, the 
> DESCRIPTION clause can only be updated with "clarifications and additional 
> information ... Otherwise, if the semantics of any previously defined object 
> are changed (i.e., if a non-editorial change is made to any clause other than 
> those specifically allowed above), then the OBJECT IDENTIFIER value 
> associated with that object must also be changed." 
> 
> So our question to the group is "Does option 2 qualify as a valid 
> "clarification and additional information" or are we forced into option 1?". 
> Option 1 would require a complete replacement MIB with corresponding impacts 
> to existing code to support the new TLS version, so I believe Option 2 would 
> be preferred, if allowed.
> 
> Regards,
> Ken Vaughn
> 
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-936-647-1910
> +1-571-331-5670 cell
> kvau...@trevilon.com
> www.trevilon.com
> 

> ___
> 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 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg