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

Andy Donati <andy.donati@comcast.net> Sun, 06 March 2022 22:18 UTC

Return-Path: <andy.donati@comcast.net>
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 66C123A0D74 for <opsawg@ietfa.amsl.com>; Sun, 6 Mar 2022 14:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOiWcVQF5Yx2 for <opsawg@ietfa.amsl.com>; Sun, 6 Mar 2022 14:17:54 -0800 (PST)
Received: from resqmta-c1p-023465.sys.comcast.net (resqmta-c1p-023465.sys.comcast.net [IPv6:2001:558:fd00:56::5]) (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 62CDB3A0D6F for <opsawg@ietf.org>; Sun, 6 Mar 2022 14:17:54 -0800 (PST)
Received: from resomta-c1p-023265.sys.comcast.net ([96.102.18.226]) by resqmta-c1p-023465.sys.comcast.net with ESMTP id QxARnzd6tbHrcQzCKn9CS3; Sun, 06 Mar 2022 22:17:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1646605072; bh=p3i1C5P80JGExgEcBphpV7kG2EgmXghq83+VJWCFdiI=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=c01KS2bIN8E5jhA/ryZ9Pq3yNR5A47wNxRaXCHYC1O7WMilcjbLUB9RPPr+2k5AQL YbVtq71Ix0qPW+b0+3Gc34j1imI7lEJHz92z/ZCXGiJDoBgXZol1slI/pbdmobqp+3 UtRAxxbv3JuaBK4twboFiw//94Zw9VgfBGqLPoOsffT9DFb8mSZM8u+DqWD7dsdEcX 66hYIxpwadjeHJOzj68YsPPTOqJuFCl+dnBfEN9VRc4l2KiI6lvi+o3NIqzOnxnJvA K+bc6H/47ePzF6IH0+GeBOB6Kg9BSjeL2q2ttnCgCqB+g5w/vPbSDJ5jQcpvQ5/ozY KmKTdqfEpo8ng==
Received: from oxapp-asc-75o.email.comcast.net ([96.118.211.81]) by resomta-c1p-023265.sys.comcast.net with ESMTPS id QzC1nxsYSlUxNQzC1n87dJ; Sun, 06 Mar 2022 22:17:34 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvvddrudduvddgudeivdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvkfgjfhfugggtrfgkofhisegrtdgssgertdejnecuhfhrohhmpeetnhguhicuffhonhgrthhiuceorghnugihrdguohhnrghtihestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepudehfeduvddtteelhfekieektdeuvdelvdefheeukefhheevhffgffeuhfefhfejnecuffhomhgrihhnpehtrhgvvhhilhhonhdrtghomhdpihgvthhfrdhorhhgnecukfhppeeliedruddukedrvdduuddrkedupddviedtudemudekugemkeektddtmegtgeehtdemgeelkedumeeiugguudemugejfhgsmeguugefugenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehogigrphhpqdgrshgtqdejhehordgvmhgrihhlrdgtohhmtggrshhtrdhnvghtpdhinhgvthepleeirdduudekrddvuddurdekuddpmhgrihhlfhhrohhmpegrnhguhidrughonhgrthhisegtohhmtggrshhtrdhnvghtpdhnsggprhgtphhtthhopeefpdhrtghpthhtohepkhhvrghughhhnhesthhrvghvihhlohhnrdgtohhmpdhrtghpthhtohepohhpshgrfihgsehivghtfhdrohhrghdprhgtphhtthhope ifjhhhnhhsudeshhgrrhgurghkvghrshdrnhgvth
X-Xfinity-VMeta: sc=-100.00;st=legit
Date: Sun, 06 Mar 2022 17:17:30 -0500
From: Andy Donati <andy.donati@comcast.net>
To: Kenneth Vaughn <kvaughn@trevilon.com>, opsawg@ietf.org, Wes Hardaker <wjhns1@hardakers.net>
Message-ID: <1920578160.1219628.1646605050563@connect.xfinity.com>
In-Reply-To: <3FC64B46-2A9B-421E-A0A2-C2B9ADB50338@trevilon.com>
References: <164653008970.31708.8719487856127881636@ietfa.amsl.com> <3FC64B46-2A9B-421E-A0A2-C2B9ADB50338@trevilon.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1219627_1257488570.1646605050529"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.5-Rev21
X-Originating-IP: 2601:18d:8800:c450:4981:6dd1:d7fb:dd3d
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Nz2p_l2znR9dPUKHHY1FNSioyF4>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-01.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Mar 2022 22:18:01 -0000

Hi Kenneth,

Thank you for the 01 draft.  Here are a few review items.

Item 1:
The Description clause for the SnmpTLSFingerprint TEXTUAL-CONVENTION has the word obsolete in quotes i.e., "obsolete" in line 185.
It is suggested that the quotes around the word obsolete be removed as it can be confusing to some compiler programs as to where the Description clause ends.


Item 2:
The size restriction for SnmpTLSFingerprint in line 564 needs to be removed because it is already defined in the Textual Convention.
snmpTlstmCertToTSNFingerprint OBJECT-TYPE
SYNTAX SnmpTLSFingerprint (SIZE(1..255)) <==


Item 3:
In section 2.2 shown below, perhaps the implementation to use authPriv should be strongly recommended instead of forced.

>> 2.2. Security Level
>> The RFC3411 architecture recognizes three levels of security:
>> * without authentication and without privacy (noAuthNoPriv)
>> * with authentication but without privacy (authNoPriv)
>> * with authentication and with privacy (authPriv)
>> With (D)TLS 1.3, authentication and privacy are always provided.
>> Hence, all exchanges conforming to the rules of this document will
>> include authentication and privacy, regardless of the security level
>> requested.
>> // This is consistent with what was prescribed in RFC6353, where a
>> // TLS Transport Model is expected to provide for outgoing
>> // connections with a security level at least that of the requested
>> // security level.

Regards,
Andy

>     On 03/06/2022 8:14 AM Kenneth Vaughn <kvaughn@trevilon.com> wrote:
> 
> 
>     This draft responds to the various comments received to date. The big changes are as follows:
>     1. It proposes the creation of a new registry, which will initially be identical to the TLS 1.2 Hashing Algorithm Identifier Table but will be separate so that we can add new rows as needed to support future algorithms without implying that those algorithms are valid for TLS 1.2. This required a corresponding edit to the SnmpTLSFingerprint object to reference the new table.
> 
>     2. It removes the previously proposed restrictions related to USM, prior SNMP versions, and CommonName. The text from RFC 6353 still apply.
> 
>     3. Several changes were made to reflect proper capitalization of key words in conformance to BCP14 and I changed a couple of "MAY NOT"s (which are ambiguous) to "MUST NOT".
> 
>     NOTE: One comment that I could not address is whether OPSAWG should also be updating RFC 7407 for YANG
> 
> 
> 
>     Specific response to comments are provided below:
>     Is this an update or a replacement?
>     Assuming the reference to a new identifier table is allowed, it is a minor update
>     Has the original author been contacted?
>     He was previously; I've included him on this email as well.
>     Remove anchors from the abstract
>     Done
>     Should this document be specific to 1.3?
>     The current approach is 100% backwards compatible with RFC 6353 so works with 1.2 and 1.3. It is impossible to know what changes will be made in the future, but the changes that have been made should make it more likely to work with future versions of TLS
>     RFC 6353 has already been updated by 8996 (i.e., prohibiting prior TLS versions)
>     Added a reference to RFC8996
>     We should not change the status of USM
>     Text removed
>     Verify all key words are marked
>     All key words have been capitalized and within the body of the document (i.e., not the MIB) they are marked with <bcp14> tags
>     Need to discuss multi-version
>     No need to as there is no real change to the MIB (just referencing a different table, but all of the objects stay the same)
>     Concerns about designating new objects with "13"
>     With adopted approach, there are no longer any new objects
>     Missing closing quote on CONTACT INFO
>     Corrected and checked MIB text with a validator
>     Update "Simplified BSD" to "Revised BSD"
>     Done
>     Detail changes in the MIB's revision clause
>     Done
> 
> 
>     I also corrected a couple of spelling errors
> 
>     Regards,
>     Ken Vaughn
> 
>     Trevilon LLC
>     6606 FM 1488 RD #148-503
>     Magnolia, TX 77354
>     +1-936-647-1910
>     +1-571-331-5670 cell
>     kvaughn@trevilon.com mailto:kvaughn@trevilon.com
>     http://www.trevilon.com
> 
> 
> 
>         > >         On Mar 5, 2022, at 7:28 PM, internet-drafts@ietf.org mailto:internet-drafts@ietf.org wrote:
> > 
> > 
> >         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           : Transport Layer Security Version 1.3 (TLS 1.3) Transport Model 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 TLS Transport Model (TLSTM), as defined in
> >           RFC 6353 to support Transport Layer Security Version 1.3 (TLS) and
> >           Datagram Transport Layer Security Version 1.3 (DTLS), which are
> >           jointly known as "(D)TLS".  This document may be applicable to future
> >           versions of SNMP and (D)TLS.
> > 
> >           This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.
> > 
> > 
> >         The IETF datatracker status page for this draft is:
> >         https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/
> > 
> >         There is also an HTML version available at:
> >         https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-01.html
> > 
> >         A diff from the previous version is available at:
> >         https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-01
> > 
> > 
> >         Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> > 
> > 
> >         _______________________________________________
> >         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
>