Re: [netconf] netconf-tls wasRe: Latest ietf-netconf-server draft and related modules

Kent Watsen <> Tue, 11 May 2021 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB3723A1EB8 for <>; Tue, 11 May 2021 10:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VpGkVc-GrP0X for <>; Tue, 11 May 2021 10:12:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E06483A1EE4 for <>; Tue, 11 May 2021 10:11:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1620753112; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ftMmJQa8n09/I4sStLCt2RxbGZOJWD1qWO2YOPAJNoA=; b=Cbx+ybjWIwfzrjOgYUMfkhFrpJkmrTGytCxftOVJ/Jr/+UCPwWh7IMELJOYsoi2q k8EJC+eworP2byP6TxBFwIGPzMqodONVCNJMKbxI16ZpnDmIr/vdzVVCPgkgvLjWJfo hQmi/H/j9U5wLj8L+JzWOtC8hJ2aUb6aTZ6xdU8s=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2ABBEA70-DF91-4BD2-B18F-EDD02B2AED10"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 11 May 2021 17:11:52 +0000
In-Reply-To: <>
Cc: "" <>
To: tom petch <>
References: <972-608a4700-29-1b90d060@24617716> <> <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.05.11-
Archived-At: <>
Subject: Re: [netconf] netconf-tls wasRe: Latest ietf-netconf-server draft and related modules
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2021 17:12:14 -0000

Hi Tom,

> I find this I-D confused about which versions of TLS are supported.  It is 1.0/1.1/1.2 or1.2/1.3 or 1.0/1.1/1.2/1.3 or 1.2 or ...
> This needs addressing and the text changed to match.

The “ietf-tls-common” module has features: "tls-1_0”, "tls-1_1”, "tls-1_2”, and "tls-1_3”.  Per this recent thread [1], my local-copy now has for all features except “tls-1_3” a comment in the “description” statement along the lines of "TLS 1.x is obsolete and thus it is NOT RECOMMENDED to enable this feature."


> I suspect that the IESG will not accept any support for 1.0 or 1.1 given the existence of an RFC deprecating them and that this I-D should not go further than putting in place hooks with which an organisation could augment such support if they wanted to, but even that may be going too far.

Disagree.  It's one thing to say that a protocol is deprecated and another to say that the configuration for a still somewhat-widely used deprecated-protocol is deprecated.

> I wonder too about what forms of authentication are acceptable, something that has changed several times in the life of the I-D.  I do  not have a view of which are and which are not but think that guidance from the TLS WG or SecDir or Security AD would be useful now rather than later.

What is there to wonder about with regards to forms of authentication?  Saying they’ve changed several times is exaggerated - they changes only once, and that was to add support for “raw public keys” and “pre-shared-keys”, per request.  AFAIK, the auth mechanisms (the two just mentioned + X.509 certs) are the minimally viable set.

> In a similar vein, TLS 1.3 is keen to ship application data before the handshake is complete, before authentication has happened, which causes problems for applications which want the handshake and authentication to complete first.  I see NETCONF as being such an application and the I-D needs to address that, as it is being addressed by other WG.

Is that really true?  How is it not considered a security hole in the protocol?!  I agree that it’s undesirable, but it’s unclear what text could be added to the “tis-client-server”, “netconf-client-server” or “restconf-client-server” drafts to address this.  Please advise.