Re: [netconf] draft-ietf-netconf-tls-client-server-34 tls-version

Kent Watsen <kent+ietf@watsen.net> Mon, 04 March 2024 18:35 UTC

Return-Path: <0100018e0abfa105-6e3e721b-bfdb-471b-b2a6-de319b0895e7-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE62C1654EC for <netconf@ietfa.amsl.com>; Mon, 4 Mar 2024 10:35:20 -0800 (PST)
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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 WtPIUitbhtBR for <netconf@ietfa.amsl.com>; Mon, 4 Mar 2024 10:35:16 -0800 (PST)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55D2C15154E for <netconf@ietf.org>; Mon, 4 Mar 2024 10:35:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1709577314; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=54LxDVmV5N7PvWj7jMXBY9rRDzb79zujGAY4yuhVN88=; b=XOb97NCzrcTKeELQfZtni7iREczh64mcF+VBWBZH7o6CZhdHxTHhYYwvCdCNmagb baS1o0Eu6cjARUTz9wnoYnmJKp4XYeZeUb64xXNeT53mMb4cRiaUWTOQhbrJEXCEx6Z DH+GeJkNtR+xnWbn6NqpkFaxsB95GNd2RAX1ZS9U=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100018e0abfa105-6e3e721b-bfdb-471b-b2a6-de319b0895e7-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D516665D-BDC5-42B1-9353-BC7224F51DC7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Mon, 04 Mar 2024 18:35:14 +0000
In-Reply-To: <485b9594-4346-45f2-ae73-0f1195242602@cesnet.cz>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Michal Vasko <mvasko@cesnet.cz>
References: <afa59a41-0fb6-47c3-a1bf-aadfa0433a5d@cesnet.cz> <0100018df764a22e-48daaa70-a779-4636-b004-91b524b556b6-000000@email.amazonses.com> <1b1fa39b-da8c-45c5-8ba2-ce72d1b54ea8@cesnet.cz> <0100018dfd4f9dbb-77e2c1f3-96c8-4dd2-afa9-a02566f98621-000000@email.amazonses.com> <5ef6227d-393b-4b5d-aaf0-363f4943e30d@cesnet.cz> <0100018e0a0255de-e6679b09-c804-4159-bd44-5ae159be4166-000000@email.amazonses.com> <485b9594-4346-45f2-ae73-0f1195242602@cesnet.cz>
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.03.04-54.240.8.33
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OK6g-GW-r8C0qooS3J9PRH9jPmg>
Subject: Re: [netconf] draft-ietf-netconf-tls-client-server-34 tls-version
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 18:35:20 -0000

Being able to set TLS min/max version on a per-connection basis seems important to me.   I have had to do this in the past (using native TLS config).  So I lean towards Option 1.  Also, Option 2 is a somewhat large change at this late stage in the publication process.

Kent


> On Mar 4, 2024, at 10:19 AM, Michal Vasko <mvasko@cesnet.cz> wrote:
> 
> Hi Kent,
> 
> I cannot really decide between the 2 solutions. Solution 2) does not bloat basic configuration with uninteresting nodes (just like TCP keepalives used to) but effectively hides configuration parameters as features. Ideally, the nodes should have default values based on the enabled features but that is not supported yet so I really cannot help you with the decision, sorry.
> 
> Regards,
> Michal
> 
> On 4. 3. 2024 16:08, Kent Watsen wrote:
>> Hi Michal,
>> 
>>> On Mar 4, 2024, at 2:09 AM, Michal Vasko <mvasko@cesnet.cz> <mailto:mvasko@cesnet.cz> wrote:
>>> 
>>> Hi Kent,
>>> 
>>> thanks, that seems good except I would not be sure what the meaning of "no configured min/max version" is. Does it depend on the implementation (so, for example, if it supports TLS 1.0 and no `min` is defined, it is supported as well) or it is derived from the TLS versions supported by the module (which depends on the enabled features)? In my opinion, it needs clarification at least in the form of more detailed descriptions and I assume it is the latter.
>>> 
>> 
>> Two possible fixes:
>> 
>>   1) make these two  leafs “mandatory true” 
>> 
>> 	PROs: forces the min/max “features”  to be enabled.
>> 	CONs: rely solely on that the full set of features are enabled.
>> 
>>   2) remove the “tls-versions” container entirely
>> 
>> 	PROs: rely solely on that features are enabled accurately.
>> 	CONs: no way to configure limits per TLS endpoint (features are global)
>> 
>> Thoughts?
>> 
>> PS: have only a few hours untill submission-cutoff, so a quick response would be appreciated.
>> 
>> Kent
>> 
>> 
>> 
>> 
>> 
>>> Regards,
>>> Michal
>>> 
>>> On 2. 3. 2024 4:57, Kent Watsen wrote:
>>>> Hi Michal,
>>>> 
>>>>> On Mar 1, 2024, at 2:11 AM, Michal Vasko <mvasko@cesnet.cz> <mailto:mvasko@cesnet.cz> wrote:
>>>>> 
>>>>> Hi Kent,
>>>>> 
>>>>> yeah, I was not sure whether you have seen it but had enough other work and then forgotten about it.
>>>>> 
>>>> Distracted by life  ;)
>>>> 
>>>>> As stated in the email, being able to set both min and max supported version makes sense to me (and is supported by OpenSSL), not so much customizing the priority of each TLS version, so that is my proposal. Thanks.
>>>>> 
>>>> Okay, so I just did this:
>>>> 
>>>> 162     container tls-versions {
>>>> 163       description
>>>> 164         "Parameters regarding TLS versions.";
>>>> 165       leaf min {
>>>> 166         type identityref {
>>>> 167           base tls-version-base;
>>>> 168         }
>>>> 169         description
>>>> 170           "If not specified, then there is no configured
>>>> 171            minimum version.";
>>>> 172       }
>>>> 173       leaf max {
>>>> 174         type identityref {
>>>> 175           base tls-version-base;
>>>> 176         }
>>>> 177         description
>>>> 178           "If not specified, then there is no configured
>>>> 179            maximum version.";
>>>> 180       }
>>>> 181     }   
>>>> 
>>>> All good?
>>>> 
>>>>> Regards,
>>>>> Michal
>>>>> 
>>>> 
>>>> Thanks again,
>>>> Kent
>>>> 
>>