Subject: Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 2 Dec 2021 06:06:24 +0000

I am expanding this CFA to give those in the tls WG a chance to comment
on the veracity of the work or provide any additional insights that can
help inform opsawg as we consider adoption.

Joe

On 11/19/21 11:27, Joe Clarke (jclarke) wrote:
> Hello, WG.  Kenneth presented
> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at IETF112
> to us, and this was previously presented at SecDispatch at IETF111.  The
> feeling there was that this work had merit, but Sec didn't have enough
> SNMP experience to be the owner.  At the AD level, the feeling was that
> perhaps opsawg did have the expertise and could pick this up.
>
> Therefore, this serves as a three week call for adoption of this draft. 
> The three weeks is being given due to the US holiday next week.  There
> has already been some comments regarding scope that have been raised
> on-list, and Kenneth has called out potential courses of action in his
> 112 presentation.
>
> Please respond by December 10, 2021 regarding your thoughts on adopting
> this work as well as comments on the work so far.
>
> Thanks.
>
> Joe
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Kenneth Vaughn <[email-masked]>
Date: Wed, 8 Dec 2021 15:00:56 -0600

As the author of this draft, I obviously support this work. I also encourage others to respond to this call prior to its closing on the 10th.

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 Nov 29, 2021, at 9:59 AM, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
> 
> Just wanted to provide a post-US Thanksgiving reminder that this call
> for adoption is ongoing and set to close on December 10.
> 
> Joe
>

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 8 Dec 2021 21:04:13 +0000

Thanks, Ken.  I might also ask if you could respond to Juergen on some of the things he found.  Perhaps you can also address Michael's concern on this same thread.

Joe

On 12/8/21 16:01, Kenneth Vaughn wrote:
As the author of this draft, I obviously support this work. I also encourage others to respond to this call prior to its closing on the 10th.

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]<mailto:[email-masked]>
www.trevilon.com<http://www.trevilon.com>

On Nov 29, 2021, at 9:59 AM, Joe Clarke (jclarke) <jclarke=[email-masked]<mailto:jclarke=[email-masked]>> wrote:

Joe

Thanks.

Joe

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Kenneth Vaughn <[email-masked]>
Date: Thu, 9 Dec 2021 08:54:36 -0600

Juergen,

It seems to me that all of these references argue for asking IANA to maintain the one-octet identifiers for the hashing algorithms (i.e., including the addition of new identifiers as new algorithms are developed), even after TLS 1.2 fades from use. That will allow the fingerprint algorithm to remain unchanged in all of these scenarios and greatly simplifies our update effort.

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 Nov 19, 2021, at 1:40 PM, Jürgen Schönwälder <[email-masked]> wrote:
> 
> Let me add one additional observation: RFC 6353 has been a blueprint
> for the YANG data model for SNMP configuration defined in RFC 7407.
> The ietf-x509-cert-to-name module, which is part of RFC 7407, defines
> a tls-fingerprint, which is also using a 1 octet hashing algorithm
> identifier. If we expand SNMP's TC, we should also look at the YANG
> equivalent. I also spotted that the YANG definition is imported by
> draft-ietf-netconf-https-notif-09.txt, I am not sure whether there are
> any other imports of this YANG definition (or the SNMP TC).
> 
> /js
> 
> On Fri, Nov 19, 2021 at 07:57:32PM +0100, Jürgen Schönwälder wrote:
>> Hi,
>> 
>> any clarifications that are necessary to run SNMP over (D)TLS 1.3 are
>> worth to work on. Looking at the document, it leaves me a bit puzzled
>> of what is actually changed. I think all text that is in RFC 6353 and
>> not modified should be removed from the update (for example, I think
>> there is no need to republish text concerning USM). For the MIB
>> module, it would help a lot if the revision clause would detail what
>> has actually changed instead of just saying "This version updated the
>> MIB to support (D)TLS 1.3." I like to see concrete text like
>> 
>> - SnmpTLSFingerprint has been depracted and SnmpTLS13Fingerprint
>>  has been introduced.
>> 
>> - The snmpTlstmCertToTSNTable has been deprecated and a new
>>  snmpTlstmCertToTSN13Table has been introduced.
>> 
>> - The snmpTlstmParamsTable has been deprecated and a new
>>  snmpTlstmParams13Table has been introduced
>> 
>> I find it problematic to embed "13" in the new object names as this
>> suggests the objects work only for TLS 1.3, which I hope is not the
>> case, i.e., I hope we do not have do yet another update when (D)TLS
>> 1.4 comes along in the future - or is the idea we actually do that? I
>> think there should also be clear guidelines what implementations
>> should do, implement the new objects and accept also D(TLS) 1.2
>> configurations via them or should the new objects only be supported
>> for D(TLS) 1.3 (and higher?) configurations?
>> 
>> /js
>> 
>> PS: There are also some bugs in the MIB module, mpTlstmAddrCount
>>    should be snmpTlstmAddrCount and CONTACT-INFO string is not
>>    terminated.
>> 
>> On Fri, Nov 19, 2021 at 04:26:50PM +0000, Joe Clarke (jclarke) wrote:
>> -- 
>> Juergen Schoenwaelder           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/>
> 
> -- 
> Juergen Schoenwaelder           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/ <https://www.jacobs-university.de/>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 9 Dec 2021 16:14:09 +0100

Ken,

note sure what "all these references" are. I am now looking at Section
15 of RFC 8447 and it states that the values in the TLS HashAlgorithm
registry are only applicable to version of (D)TLS protocol versions
prior to 1.3. This does not necessarily imply that we can't continue
to use them for the fingerprint algorithm. Hence, this might have all
been a false alarm... Perhaps we need to let IANA know somehow that
there are non (D)TLS specifications depending on the registry values
so that they can take a note in case people in the future want to
deprecate the registry.

/js

---

From: Kenneth Vaughn <[email-masked]>
Date: Thu, 9 Dec 2021 10:06:17 -0600

Without a doubt, the review of this document requires both SNMP experts and TLS experts. Based on my presentations to both areas (SecDispatch and OPSAWG), it would appear that both have concerns that they do not have adequate expertise - nonetheless, there appears to be consensus that the work needs to be done. In short, we need a home and we need to make sure that we then outreach to ensure adequate expertise. 

It should be noted that this is largely how my draft was developed. With the aid of limited USDOT funding, I was able to gain the assistance of Dr. Michaela Vanderveen, who is a security expert, whereas I made sure the MIB and other aspects were properly aligned with SNMP. While I do not speak for the USDOT, I suspect if there is a need for more targeted assistance that it can be acquired - but ideally, we can find experts from the IETF community to provide input. In either case, I am confident that we can get this properly reviewed by the necessary experts.

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 Nov 20, 2021, at 9:24 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> Joe Clarke \(jclarke\) <jclarke=[email-masked]> wrote:
> I guess I missed this from IETF111.
> I scanned the document briefly, and I don't see that much that requires
> *SNMP*-fu, so much as it requires TLS-fu.
> 
> I think that the document will get lost in OPSAWG.
> 
> Traditionally, WGs do their own MIB modules... so I don't understand why it
> is not in TLS.
> 
> --
> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Kenneth Vaughn <[email-masked]>
Date: Thu, 9 Dec 2021 10:17:20 -0600

> "all these references"
RFC 7407
draft-ietf-netconf-https-notif-09.txt
any other imports of this YANG definition

> the values in the TLS HashAlgorithm
> prior to 1.3.  Perhaps we need to let IANA know somehow that
Correct, based on my reading of the standards, I was concerned that, at some point in the future, hash algorithms might not be assigned the one octet identifier. This concerned seemed to be shared by several others (e.g., including those in the TLS community). If we can convince IANA to continue to assign the one octet values, we should be able to continue to use the existing fingerprint algorithm. That would then make this update quite minor, although I believe it still necessary to clarify other ambiguities that arise.

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 Dec 9, 2021, at 9:14 AM, Jürgen Schönwälder <[email-masked]> wrote:
> 
> Ken,
> 
>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/> <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>>
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg> <https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg>>
> 
> --

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 9 Dec 2021 17:29:11 +0100

> Correct, based on my reading of the standards, I was concerned that, at some point in the future, hash algorithms might not be assigned the one octet identifier. This concerned seemed to be shared…

I am not sure we should go and try to fix problems that are not yet
concrete problems. I looked at the numbers registered and there is
lots of space left.

/js

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 15 Dec 2021 18:42:03 +0000

The CFA has concluded, and judging by the discussion, there is enough
interest to adopt this work.

Ken, please rename the draft as draft-ietf-opsawg-tlstm-update-00 and
submit it to IETF DataTracker.  One of the fields on the submission page
is the document this replaces.  Indicate that this replaces
draft-vaughn-tlstm-update.  DO NOT make any other changes to the
document other than its name and revision for this initial submission.

Some of the comments raised in the CFA were around making sure we have
requisite TLS expertise to review.  We extended the CFA to the tls WG,
and we will continue to engage there to ensure proper review.  Of
course, we will also work with SEC DIR as the document progresses.

Another major question was whether or not we can continue to use
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
for the TLSHashAlgorithm identifier.  Doing so would greatly simplify
things.  We will check with the registry experts to see if this can
continue to be used (though this might have to wait until Jan).

Joe

---

From: tom petch <[email-masked]>
Date: Fri, 17 Dec 2021 17:28:54 +0000

Some initial thoughts for a -01

The anchors need to go from the Abstract

RFC6353 is a Standard - there is then a process issue as to whether or not this is still a standard!

Conventions lacks RFC8174

s.4 The TLP is out of date.  The current one has Revised not Simplified

Has there been any feedback from the author of RFC6353?  Should be be a co-author?

Does this update or replace RFC6353?

RFC6353 has already been updated by RFC8996.  I think that this I-D needs to be clear which updates have already happened.

This I-D sets out to be all singing all current TLS supporting.  Should it just be TLS1.3?

Do the updates fall within those permitted by SMI or should this be a newMIB branch?

Tom Petch
________________________________________
From: OPSAWG <[email-masked]> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]>
Sent: 15 December 2021 18:42

Joe