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

Kenneth Vaughn <kvaughn@trevilon.com> Tue, 27 September 2022 16:51 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 1687FC159821 for <opsawg@ietfa.amsl.com>; Tue, 27 Sep 2022 09:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 X472VWlXne1n for <opsawg@ietfa.amsl.com>; Tue, 27 Sep 2022 09:51:11 -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 EF770C1594AE for <opsawg@ietf.org>; Tue, 27 Sep 2022 09:51:10 -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=FLBXqpdIL5Kq9NV9kW240QUlOOmJAI4Uj3CRfaR0FfM=; b=C3ZZP1tsodryPZH/4f3vFU3Kna lpqAl7cEwxFpZOXZIfPBWfybkORebIV/hwIrl6CR7n2VIiHscISvcnGNr+ixMJ/e05HXfnI8zxCq/ x8FhSo3agLxvznyI76hwp9oVB;
Received: from net9-155.cvctx.com ([66.220.129.155]:64917 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 1odDnZ-0000ws-Qk; Tue, 27 Sep 2022 16:51:09 +0000
From: Kenneth Vaughn <kvaughn@trevilon.com>
Message-Id: <F86FF076-3D12-4F2D-BEFF-996679C88EA4@trevilon.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_89971A7C-0C1E-41F7-8928-1C55D3B77975"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 27 Sep 2022 11:51:08 -0500
In-Reply-To: <BN9PR11MB537103C29F1F2300DD1C10E1B8559@BN9PR11MB5371.namprd11.prod.outlook.com>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
References: <BN9PR11MB537103C29F1F2300DD1C10E1B8559@BN9PR11MB5371.namprd11.prod.outlook.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: <https://mailarchive.ietf.org/arch/msg/opsawg/0Q2MdpsXCNt03c3tq5ybijuqtZU>
Subject: Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 27 Sep 2022 16:51:15 -0000

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 consensus (i.e., no sustained objections) on the wording in the current draft due to the fact that there was agreement that there was no requirement for our fingerprint to use the same hash as used by the TLS layer (and thus no technical requirement to link the two registries). From that point, we concluded that if anyone wanted a value, they "would find the energy to register it" and we would not clutter the registry with unnecessary values.

Personally, I see the argument on both sides and am fine with the consensus. However, I could perhaps see softening the expert review statement to automatically approve the request to add any hash algorithm that is already approved for any version of TLS or DTLS rather than fording a consultation with the TLS WG.

I've made the other changes, but will hold off on implementing them until we resolve this issue..

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-571-331-5670 cell
kvaughn@trevilon.com
www.trevilon.com

> On Sep 27, 2022, at 10:36 AM, Joe Clarke (jclarke) <jclarke@cisco.com> wrote:
> 
> I am reviewing -07 of this draft ahead of the shepherd review.  I have found a few nits, but at a larger level, I think more text might be needed for IANA around how to handle the new TLS hash registry.  Currently, the draft talks about a sync to “IANA TLS HashAlgorithm Registry”, which is good.  But what if new values get added to the cipher suites registry?  For example, what about GOST variants?  I would think if the TLS 1.3 spec (and their experts) allow for these algorithms would this registry not just take them?  What would the expert review consider when adding new algorithms here?
>  
> In terms of nits:
>  
> Search for “ciphersuites” and change to “cipher suites” as that is more consistent with other documents (and I think you use both in this document).
>  
>  
> Section 2.1:
>  
> s/Values zero through 2/Values 0 through 2/
>  
>  
> Section 2.3:
>  
> s/stated that TLSTM/states that TLSTM/
>  
>  
> Section 3.1:
>  
> s/request, offer or use/request, offer, or use/
>  
>  
> Section 7
>  
> Add a period to the end of the section.
>  
> Joe