Subject: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)

From: Kenneth Vaughn <[email-masked]>
Date: Wed, 20 Oct 2021 22:38:04 -0500

I would like to present https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ <https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/>. This document is a proposal to update to RFC 6353 (TLS Transport Model for SNMP) to reflect the needs of TLS 1.3. 
As a little bit of background, SNMP is widely used within Intelligent Transportation Systems (ITS) to monitor, manage and control field devices, as defined in the National Transportation Communication for ITS Protocols (NTCIP) standards, ISO standards, and specifications in the United Kingdom. As you may know, CISA has declared the transportation infrastructure to be “critical infrastructure”, and the ITS community is very interested in ensuring that this infrastructure is adequately protected, especially as these systems are increasingly relied upon by modern connected vehicles. 

RFC 6353 defines how to use (D)TLS 1.2 authentication to control data access within SNMP. Unfortunately, its design is not entirely compatible with TLS 1.3. As such, the ITS community is interested in producing an update to RFC 6353 and believes it would be in everyone's best interests to produce this document as an IETF publication, assuming that its development can proceed in a timely manner. 
In an effort to promote further discussion on this topic, the NTCIP and ISO communities have requested that I reach out to the IETF to initiate a conversation on this topic. I was originally directed to the SECDISPATCH group and based on my presentation to that group at IETF 111, the decision was made to redirect this effort to OPSAWG. The presentation I made to the SECDISPATCH group is available at https://trevilon.com/download/RFC6353Proposal.pptx <https://trevilon.com/download/RFC6353Proposal.pptx>; this presentation explains the motivation behind this update proposal.

Many thanks for your considerations and I look forward to our future discussions. Please let me know if you have any questions.
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

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 20 Oct 2021 23:38:01 -0700

Hi -

On 2021-10-20 8:38 PM, Kenneth Vaughn wrote:
> I would like to present 
> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ 
> <https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/>. This 
> document is a proposal to update to RFC 6353 (TLS Transport Model for 
> SNMP) to reflect the needs of TLS 1.3.

It seems to me that the document combines two distinct proposals:
   (1) deprecating most of the MIB Module from RFC 6353
   (2) defining a new transport model and putting its management
       interface into the gutted shell left behind from 6353.

I think the document would be easier to digest if it were simply
crafted to be solely what its title says it is: a Transport Layer 
Security Verion 1.3 (TLS 1.3) Transport Model for SNMPv3.  Any
question of casting support for (D)TLS 1.2 into the outer darkness
of "historical" classification or deprecating 6353's MIB module's
definitions could then be handled separately.

Randy

---

From: Kenneth Vaughn <[email-masked]>
Date: Thu, 21 Oct 2021 15:28:24 -0500

Randy,

If I properly understand your suggestion, you are requesting that we make the new document a stand-alone document and the group could separately consider the retirement of RFC 6353 - perhaps on a separate timeline. If this is an accurate summary of your request, it is largely captured by our original draft (https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/00/ <https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/00/>). The only caveat is that version 00 did not include support for DTLS 1.3 because it had not been finalized when we wrote that draft. Once DTLS 1.3 was finalized, the number of changes became much smaller and the concept of doing an update seemed to make more sense, but it was still debated among our team members. We largely picked the update format just to show that either could be done. We are happy to follow the consensus of the group on this point. I think this is probably one of the two most important questions to answer (i.e., should we produce a stand-alone document or an update?)

The other key question (which might impact the answer to the first) is whether the change to the MIB is necessary or if we can convince IANA to maintain the one-octet hash algorithm identifier such that we can have confidence that there will always be a unique number that we can use. That would solve most of our problems (but perhaps add to the workload of IANA) as I think any changes to the MIB would become trivial. As a result, the update document would become very short.

I would be very encouraged if we are able to gain consensus on those two topics by the end if IETF 112. 

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 Oct 21, 2021, at 1:38 AM, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
> crafted to be solely what its title says it is: a Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for SNMPv3.  Any
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 21 Oct 2021 14:12:09 -0700

Hi -

On 2021-10-21 1:28 PM, Kenneth Vaughn wrote:
...
> If I properly understand your suggestion, you are requesting that we 
> make the new document a stand-alone document and the group could 
> separately consider the retirement of RFC 6353 - perhaps on a separate 
> timeline.
...

That seems sensible to me.  It might have the advantage of being
(potentially) less confusing during phased deployments, and I can
imagine situations in which management infrastructure might need
to support both - those transitions always seem to take longer than
anyone would like.

> The other key question (which might impact the answer to the first) is 
> whether the change to the MIB is necessary or if we can convince IANA to 
> maintain the one-octet hash algorithm identifier such that we can have 
> confidence that there will always be a unique number that we can use. 
> That would solve most of our problems (but perhaps add to the workload 
> of IANA) as I think any changes to the MIB would become trivial. As a 
> result, the update document would become very short.

As I understand it, RFC 5246 already established an IANA-maintained
registry in section 12, saying:
       TLS HashAlgorithm Registry: The registry has been initially
       populated with the values described in Section 7.4.1.4.1.  Future
       values in the range 0-63 (decimal) inclusive are assigned via
       Standards Action [RFC2434].  Values in the range 64-223 (decimal)
       inclusive are assigned via Specification Required [RFC2434].
       Values from 224-255 (decimal) inclusive are reserved for Private
       Use [RFC2434].

The registry seems to still observe those constraints:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18

I *think* that provides exactly what you're asking for.  If the
assignment hasn't already been made, your document could be, depending
on what the WG thinks of it, the Standards Action or "required
Specification" needed to make it happen through its own IANA
considerations section.

It sounds to me like it might be possible to just spell out the
new elements of (protocol) procedure, the two(?) OBJECT IDENTIFIERS
for these transport domains, the IANA considerations, and you'd be
pretty much done.  But TLS in all its subtle glory isn't my thing;
if you haven't already done so, reach out to Wes Hardaker.

Randy