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

Kenneth Vaughn <kvaughn@trevilon.com> Thu, 21 October 2021 20:28 UTC

Return-Path: <kvaughn@trevilon.com>
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 032DF3A0AA5 for <opsawg@ietfa.amsl.com>; Thu, 21 Oct 2021 13:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvuzBIuKVnJH for <opsawg@ietfa.amsl.com>; Thu, 21 Oct 2021 13:28:27 -0700 (PDT)
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 187853A0A94 for <opsawg@ietf.org>; Thu, 21 Oct 2021 13:28:26 -0700 (PDT)
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=eAFUt1kRAjIqnztA+r4PeS5bx7/6eQ1r1KepYnbGa+Q=; b=QY+KMxfy5M+zsmiLQvaBK2VRX2 VvNZ+kt7CGg4xyk3FavlQx2w4r03IYpCKJU28XZoQ+CwmdZ9nmmCysSFDrSei6NtBPmPu0SBhfDAG QLT2TODZnZE5Pr9XQOqu6m2X9;
Received: from net9-155.cvctx.com ([66.220.129.155]:44581 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 <kvaughn@trevilon.com>) id 1mdefp-0006A8-KN; Thu, 21 Oct 2021 20:28:25 +0000
From: Kenneth Vaughn <kvaughn@trevilon.com>
Message-Id: <DCBB6926-5A18-4703-9D81-30190B8FB985@trevilon.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_90F176E3-5783-440E-9288-97BFFE912BA2"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 21 Oct 2021 15:28:24 -0500
In-Reply-To: <15342ee1-33f2-5930-49aa-4a6725718154@alumni.stanford.edu>
Cc: opsawg@ietf.org
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
References: <344570CB-D536-4FE5-82B9-32E8F8B63277@trevilon.com> <15342ee1-33f2-5930-49aa-4a6725718154@alumni.stanford.edu>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
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: <https://mailarchive.ietf.org/arch/msg/opsawg/eCIhILTYOABCr4USH7fNwR5pnY4>
Subject: Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)
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: Thu, 21 Oct 2021 20:28:32 -0000

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

> On Oct 21, 2021, at 1:38 AM, Randy Presuhn <randy_presuhn@alumni.stanford.edu> 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/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
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg