Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-14.txt

the Operations and > Management Area Working Group (OPSAWG) WG of the IETF. > > Title : Updates to the TLS Transport Model for SNMP > Author : Kenneth Vaughn > Filename: draft-ietf-opsawg-tlstm-update-14.txt > Pages : 34 > Date

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt

concerned that the anchored object > wasn’t of the type (thinking of other examples like ifType). > > Joe > > From: OPSAWG on behalf of Randy Presuhn > > Date: Thursday, March 2, 2023 at 13:23 > To: Joe Clarke (jclarke) , Kenneth Vaughn > , opsawg@ietf.org > Subje

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt

rom the on-line Internet-Drafts > directories. > This Internet-Draft is a work item of the Operations and Management Area > Working Group WG of the IETF. > >Title : Updates to the TLS Transport Model for SNMP >Author : Kenneth Vaughn > Filename

Re: [OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

eed to be revisited anyway to determine if we want to > allow its use”. But I don’t have super strong opinion about it. > > //Zahed > > >> On 1 Mar 2023, at 20:30, Kenneth Vaughn wrote: >> >> Thank you for your comment, while it is an interesting question, I thin

Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-tlstm-update-12: (with DISCUSS and COMMENT)

Thank you for your input. I have made the revisions identified below... Please note the one question that I have about how to document RFC editor requests. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com >

Re: [OPSAWG] Francesca Palombini's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Thank you for your comment, I have revised the IANA considerations to read: The "recommended" column indicates "Y" for hashing algorithms that are standards track and are deemed to be acceptable for widely applicable current use and "N" for hashing algorithms that reflect meanings that are not

Re: [OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Thank you for your comment, while it is an interesting question, I think the wording is appropriate as is. I believe the proper interpretation of this text is that renegotiation is not supported for TLS 1.3 and we have not designed anything to allow for renegotiation (i.e., for any version of

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Thank you for your input, I hope to have a new version posted today with the change mentioned below Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > # Éric Vyncke, INT AD, comments for

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Good catch; I have corrected this and hope to have a new version available later today. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > > I noticed one nit that I don’t think I’ve seen mentioned yet, “SMNPv3” -> >

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Thank you for your comments. I have responded per below and hope to have a new version available today. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com >

Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

See responses below Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > ### Paragraph 2 > ``` >Updates to the TLS Transport Model for SNMP > draft-ietf-opsawg-tlstm-update-12 > ``` >

Re: [OPSAWG] Last Call: (Updates to the TLS Transport Model for SNMP) to Proposed Standard

Thank you for your input. I will make the requested change in the next release, which I hope to complete today. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > On Feb 16, 2023, at 12:03 PM, Jonathan Hammell wrote:

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-tlstm-update-11

I have uploaded an update that more accurately indicates that a "session" is a secure association between two instances of the TLSTM. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com

Re: [OPSAWG] AD review of draft-ietf-opsawg-tlstm-update-10

and GET/SET (read/change/create/delete) the objects > in this MIB module. > > Suggest eliding the "even then" since the sentence starts with "Even ..." Corrected by deleting the "even then" > (7) p 31, sec 8.2. Informative References > > Kenneth Vaugh

Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

if they only used IP > addresses. > > But for completeness, I would recommend doing option #4 below (as you added > normative language to v4 and v6 addresses already). > > Joe > > From: Kenneth Vaughn mailto:kvau...@trevilon.com>> > Date: Thursday, October 6, 2022 at

Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

new document, you should include the same references in the Norm/Inform. > > > This has been a problem with YANG for years and the accepted solution is to > include a section 4.1 'This module makes references to [RFC1123], [RFC5890] > etc ' > > Consistency with YANG would

Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

rg/archive/id/draft-ietf-opsawg-tlstm-update-08.txt>. > Please work through and address these. Thanks. > > Joe > > From: Joe Clarke (jclarke) > Date: Tuesday, September 27, 2022 at 13:00 > To: Kenneth Vaughn > Cc: opsawg@ietf.org > Subject: Re: SHEPHERD REVIEW: dra

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-08.txt

ote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > >Title : Updates to the TLS Transport Model for SNMP >

Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

The concept of automatically registering new hash algorithms was discussed during a May e-mail thread. Jürgen objected to the automatic recording of values and Tom Petch argued for the automatic registration. While I don't think we ever achieved "agreement" on the position, we concluded with

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-07.txt

gt; directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > >Title : Updates to the TLS Transport Model for SNMP > Author : Kenneth Vaughn > Filename: draft-ietf-opsawg-tlstm-update-07.tx

Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt

> From: OPSAWG on behalf of Joe Clarke (jclarke) > > Date: Monday, September 12, 2022 at 15:24 > To: Kenneth Vaughn , opsawg@ietf.org > Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt > > Thanks, Ken. Your new text addresses my concern on the use of MUST

Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt

ck on any interested shepherd, so I’ll > take this one up and move this forward to IESG. I will have the shepherd > review and write-up ready this week. > > Joe > > From: OPSAWG on behalf of Joe Clarke (jclarke) > > Date: Monday, September 12, 2022 at 15:24 >

Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt

ailable from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > >Title : Updates to the TLS Transport Model for SNMP > Author : Kenneth Vaughn > Filename

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tlstm-update

way I read the SnmpTLSAddress paragraph, “may not” > makes more sense. For example, if the value of the object that uses this TC > is a hostname, I cannot use it directly without doing DNS resolution on it. > However, if it’s an IP address, I can use it directly (because if not, the

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tlstm-update

22, at 3:38 AM, tom petch wrote: > > From: OPSAWG mailto:opsawg-boun...@ietf.org>> on > behalf of Kenneth Vaughn mailto:kvau...@trevilon.com>> > Sent: 25 August 2022 22:00 > > I have no real problem with revising the phrase you have identified, but the > re

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tlstm-update

I have no real problem with revising the phrase you have identified, but the revision needs to be unambiguous. The phrase "may not" is ambiguous as it can be interpreted as meaning: - not allowed, in which case "MUST NOT" is the better BCP14 phrase - an attempt to softly say not allowed, but

Re: [OPSAWG] POLL FOR IPR: draft-ietf-opsawg-tlstm-update

No, I am not aware of any IPR that applies to this draft. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > On Aug 11, 2022, at 3:44 AM, Joe Clarke (jclarke) wrote: > > Authors and contributors, please

[OPSAWG] draft-ietf-opsawg-tlstm-update-05.txt

I have posted the latest update to the TLSTM draft at https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-05.html . It includes the following changes: Removed the duplicate "Table 1:" text in the caption Changed

[OPSAWG] draft-ietf-opsawg-tlstm-update-04

I have uploaded a new version of the TLSTM document. This version clarifies the process to update the SNMP-TLSTM registry and clearly indicates the existing assignments while prohibiting the use of 'none', 'md5', and 'sha1'. The only open issue at this time is the following paragraph: > In

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-03.txt

n modern TLS, I think they only register entire > ciphersuites, do we really expect them to go an register any new hash > algorithm that comes along into the registry of hash algorithms for > producing certificate fingerprints? > > I understand the "we are too lazy to do this"

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-03.txt

t;> >>> And what about this: >>> >>> [...] In addition, a new entry >>> MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a >>> new hash algorithm is approved for any version of TLS or DTLS. >>> >>> Why would that b

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-03.txt

the TLS internal usage of hash algorithms. > > /js > > On Thu, May 05, 2022 at 10:09:45AM -0500, Kenneth Vaughn wrote: >> I have uploaded a new version of the "Updates to the TLS Transport Model for >> SNMP". This version includes the following changes: >>

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-03.txt

-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > >Title : Updates to the TLS Transport Model for SNMP >Author : Kenneth Vaughn >

Re: [OPSAWG] [TLS] draft-ietf-opsawg-tlstm-update-02.txt

TLSTM was the name given to it by RFC 6353 and does provide the full context (i.e. a transport model), so I am hesitant to change that part, but I don't see any problem with calling it SNMP-TLSTM registry. I will make that change in the next version. Regards, Ken Vaughn Trevilon LLC 6606 FM

[OPSAWG] draft-ietf-opsawg-tlstm-update-02.txt

Magnolia, TX 77354 +1-936-647-1910 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-opsawg-tlstm-update-02.txt > Date: April 6, 2022 at 6:38:45 PM CDT > To

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-01.txt

are aware of this anomaly and that the request should be transmitted with authentication and privacy rather than TLSTM responding with an error. I believe our proposal is 100% consistent with the RFC 6353 specification. If I am misunderstanding your suggestion, perhaps you can offer replaceme

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-01.txt

el for the Simple Network Management Protocol Version 3 (SNMPv3) >Author : Kenneth Vaughn > Filename: draft-ietf-opsawg-tlstm-update-01.txt > Pages : 33 > Date: 2022-03-05 > > Abstract: > This document updates the TL

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

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

[OPSAWG] RFC 6353 Update to support TLS 1.3

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

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)

There seems to be consensus that the update should retain the RFC 6353 position regarding USM. I will make sure the next draft reflects that decision. 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

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)

Tom, Joe, Wes, et al: I propose that we address the overarching questions first as they potentially affect the entire scope of the draft. Namely: Can we can continue to use <> <>https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18

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)

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

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)

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

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)

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

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)

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

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

on.com www.trevilon.com > On Oct 21, 2021, at 1:38 AM, Randy Presuhn > wrote: > > 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/draf

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

I would like to present 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