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

Michal Vasko <mvasko@cesnet.cz> Mon, 04 March 2024 15:19 UTC

Return-Path: <mvasko@cesnet.cz>
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 0E489C14CE33 for <netconf@ietfa.amsl.com>; Mon, 4 Mar 2024 07:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=cesnet.cz
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 WZ2xpRKFXUvx for <netconf@ietfa.amsl.com>; Mon, 4 Mar 2024 07:19:41 -0800 (PST)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:ff05:10b::237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D5EC14F75F for <netconf@ietf.org>; Mon, 4 Mar 2024 07:19:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1709565576; bh=PJHN/y1oJh6m+RwfDoHyEt2MVA6QsIwiHuigWi9f49U=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=C+Iovmxe/kZukj82yt4Xgd8KN7zRM2T78IiruqXs27lTx/8FyeBNO3xyxa79qdhqy cTpH57S6pY3aMlSg81SSYIuXI7ZpKYXSDi5RFXDSyE7Ce1cUGSmZjk/lIp/3BERjF7 Y3heA/n5nxCZRjpdw1r9h4s/DimfQJ7OvwNmBW6lhMO/9GG74ZV26KMHx63DkfdU2o 71/EgjM+bfAG8WWH0mMH6AZvnGokzRaSRBCy3PnTR6SqW/mcOetq2qP/mpRLCpTj6R uG+6ALp2gsy5IBlShhflebOiZxBTlh9ZxPQDkrQMkLJC8Q69iFgm0lHeK3gXX8Hx7U AqSMZII0NhUPQ==
Received: from [IPV6:2001:67c:1220:80c:0:7f8:37ba:2b19] (unknown [IPv6:2001:67c:1220:80c:0:7f8:37ba:2b19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 29A0C118007D; Mon, 4 Mar 2024 16:19:35 +0100 (CET)
Message-ID: <485b9594-4346-45f2-ae73-0f1195242602@cesnet.cz>
Date: Mon, 04 Mar 2024 16:19:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Kent Watsen <kent+ietf@watsen.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>
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>
From: Michal Vasko <mvasko@cesnet.cz>
In-Reply-To: <0100018e0a0255de-e6679b09-c804-4159-bd44-5ae159be4166-000000@email.amazonses.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070403020306060402090701"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/J44EVtAxrrj1aGNVD_OaAJJVLCA>
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 15:19:46 -0000

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> 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> 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
>>>
>