From nobody Wed Mar 1 17:27:27 2023 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03759C151AFA; Wed, 1 Mar 2023 17:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=trevilon.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOPBhuOQtqHF; Wed, 1 Mar 2023 17:27:21 -0800 (PST) Received: from tre.trevilon.com (tre.trevilon.com [198.57.226.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B60C151AEF; Wed, 1 Mar 2023 17:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hiFn4+mWc5z3xtFA8Z5EsHutBPJhL99aT81olapWrYU=; b=aLHDlT1FyYYa/tm8Ft3r9eX8w9 +lS67Geg35ZM42LwlHhdhS498uM2X/iBKXYopMdZc9jsz8E2BcOvcdS3zUvtkLaLnEFoNF8MgGchj /1nlL47Lij45pXd4fxA50gQi7; Received: from [98.97.177.125] (port=29663 helo=smtpclient.apple) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pXXj5-0002tk-Ma; Thu, 02 Mar 2023 01:27:19 +0000 From: Kenneth Vaughn Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BD3C695F-65F4-487E-A005-874283586D2A" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Date: Wed, 1 Mar 2023 20:27:17 -0500 In-Reply-To: <167771205903.56730.17829440635072077510@ietfa.amsl.com> Cc: The IESG , draft-ietf-opsawg-tlstm-update@ietf.org, opsawg@ietf.org, opsawg-chairs@ietf.org To: Paul Wouters References: <167771205903.56730.17829440635072077510@ietfa.amsl.com> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - tre.trevilon.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trevilon.com X-Get-Message-Sender-Via: tre.trevilon.com: authenticated_id: kvaughn@trevilon.com X-Authenticated-Sender: tre.trevilon.com: kvaughn@trevilon.com Archived-At: Subject: Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-tlstm-update-12: (with DISCUSS and COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2023 01:27:27 -0000 --Apple-Mail=_BD3C695F-65F4-487E-A005-874283586D2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 kvaughn@trevilon.com www.trevilon.com > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Should Section 2.3 or the Security Considerations not reference RFC = 9325 > "Recommendations for Secure Use of Transport Layer Security (TLS) and > Datagram Transport Layer Security (DTLS)" ? For one thing, it = documents > that if one needs to still use TLS 1.2, what options should be used or = avoided. I have added a sentence to the Security Considerations section as = follows: Implementations should consider the latest recommendations on the use of = (DTLS), such as that documented in [RFC9325]. NOTE: Within the ITS industry, our current plan is to write our = standards to require TLS 1.3 due to the fact that the current = deployments of secure SNMP are very limited and we feel it is better to = minimize variations at this point than to address the migration path - = especially since these standards will not be finalized and deployed for = at least a year or more. If you think this is ill-advised, I would be = happy to hear the arguments for allowing 1.2. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > REVISION "202209090000Z" > DESCRIPTION "This version of this MIB module is part of > RFC XXXX; see the RFC itself for full legal > notices. This version: >=20 >=20 > It will be easy to miss this "RFC XXXX" for the RFC Editor, can be = make a clearer note > for the RFC editor to update that? Happy to do so, but I'm not sure what you are looking for (I was under = the impression that this is how I was supposed to document it and that = the RFC editor checked for this text). Is there some special code that I = am supposed to use to grab their attention? > The REVISION is a date. Should that be updated to the publication = date, or is it used > as a sort of early code point ? It is unclear to me exactly what date this is supposed to point to, but = I have updated it to today since I added the OID due to another comment. > Historically, the 1-octet hashing algorithm identifier was > 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. >=20 > I'm not sure "obsolete" is the right word? >=20 > Also, looking at: >=20 > = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-18 > snmpTlstmCertCommonName OBJECT-IDENTITY >=20 > I don't see a note the registry is closed. >=20 > Perhaps weaken the claim to just "however, this registry is no longer = in use for TLS 1.3 > and above and are not expected to have any new registrations added to = it." Change made >=20 > The policy for updates is Expert Review. >=20 > Why not specification required or RFC required? (Or split the range, = as Roman alluded to as well) There was a specific WG request to allow values that were not documented = in an RFC (whether any=20 will be allowed is another question, but there was at least one person = who felt strongly about it and=20 there does not seem to be any real disadvantage. >=20 --Apple-Mail=_BD3C695F-65F4-487E-A005-874283586D2A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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
kvaughn@trevilon.com
www.trevilon.com

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Should Section 2.3 or the Security = Considerations not reference RFC 9325
"Recommendations for = Secure Use of Transport Layer Security (TLS) and
Datagram = Transport Layer Security (DTLS)" ? For one thing, it documents
that if one needs to still use TLS 1.2, what options should = be used or avoided.
I have = added a sentence to the Security Considerations section as = follows:

Implementations should = consider the latest recommendations on the use of (DTLS), such as that = documented in [RFC9325].

NOTE: = Within the ITS industry, our current plan is to write our standards to = require TLS 1.3 due to the fact that the current deployments of secure = SNMP are very limited and we feel it is better to minimize variations at = this point than to address the migration path - especially since these = standards will not be finalized and deployed for at least a year or = more. If you think this is ill-advised, I would be happy to hear the = arguments for allowing 1.2.

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

=        REVISION =    "202209090000Z"
=        DESCRIPTION "This version of = this MIB module is part of
=             &n= bsp;  RFC XXXX; see the RFC itself for full legal
= =             &n= bsp;  notices.  This version:


It will be easy to miss this "RFC XXXX" for = the RFC Editor, can be make a clearer note
for the RFC = editor to update that?
Happy = to do so, but I'm not sure what you are looking for (I was under the = impression that this is how I was supposed to document it and that the = RFC editor checked for this text). Is there some special code that I am = supposed to use to grab their attention?

The REVISION is = a date. Should that be updated to the publication date, or is it used
as a sort of early code point ?
It is unclear to me exactly = what date this is supposed to point to, but I have updated it to today = since I added the OID due to another comment.

       Historically, the 1-octet hashing = algorithm identifier was
=        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.

I'm not sure = "obsolete" is the right word?

Also, looking = at:

https://www.iana.org/assignments/tls-parameters/tls-parameters.= xhtml#tls-parameters-18
snmpTlstmCertCommonName = OBJECT-IDENTITY

I don't see a note the = registry is closed.

Perhaps weaken the = claim to just "however, this registry is no longer in use for TLS 1.3
and above and are not expected to have any new registrations = added to it."
Change = made



=        The policy for updates is = Expert Review.

Why not specification = required or RFC required?  (Or split the range, as Roman alluded to = as well)
There was a = specific WG request to allow values that were not documented in an RFC = (whether any 
will be allowed is another question, but = there was at least one person who felt strongly about it = and 
there does not seem to be any real = disadvantage.


= --Apple-Mail=_BD3C695F-65F4-487E-A005-874283586D2A--