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

Michal Vasko <mvasko@cesnet.cz> Mon, 04 March 2024 07:09 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 D7A8DC14E515 for <netconf@ietfa.amsl.com>; Sun, 3 Mar 2024 23:09:57 -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_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 EfObzUFyDy1s for <netconf@ietfa.amsl.com>; Sun, 3 Mar 2024 23:09:53 -0800 (PST)
Received: from office2.cesnet.cz (office2.cesnet.cz [78.128.248.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 D6E8FC14F682 for <netconf@ietf.org>; Sun, 3 Mar 2024 23:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1709536168; bh=4o+cZFNm4DKmiGdLKWhCfw6CPZ1jiaRIgTwzNN3haLQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=cTlhcC3TQoUi8V9T4HaC7e2UHKF8ArfS1L77r3fvZ9Q6eMUgI5EVPcUHcOa0fblyy Zq9HpS71GLH7563iTbL55vAEW5H0O7rFnOlfW5BkzmNosi3cpENJbm2vKdZD4oZbzb UVKKoVrZeIqloVawKF9BVOxbsN9uFaXuIL9fUpuiOhCAQUMLi42SzVszRNRBrX983N fk9WEY4RfFRFiPoXLZxJuyvbiZp3N8pmmwdhi2PNLHQBxAIUIReT3TaSK7mAI5u2NB 2dcG5kyVIHhDQ9Og34eU/PCGWbXv7ZBdCans11DpzPimy8ACnz0qv/KYn2B7PIy9kN V048xZHCFri0Q==
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 A73A6118007E; Mon, 4 Mar 2024 08:09:26 +0100 (CET)
Message-ID: <5ef6227d-393b-4b5d-aaf0-363f4943e30d@cesnet.cz>
Date: Mon, 04 Mar 2024 08:09:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
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>
Content-Language: en-US
From: Michal Vasko <mvasko@cesnet.cz>
In-Reply-To: <0100018dfd4f9dbb-77e2c1f3-96c8-4dd2-afa9-a02566f98621-000000@email.amazonses.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030209090500000505080507"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yadbV5uf7nb9IN3s0wVmgklv-5A>
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 07:09:57 -0000

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.

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
>