Re: [netconf] netconf-tls wasRe: Summary of updates

Kent Watsen <> Tue, 25 May 2021 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7982E3A115F for <>; Tue, 25 May 2021 15:55:37 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 5q1L_u9qlzjQ for <>; Tue, 25 May 2021 15:55:34 -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 B00963A115E for <>; Tue, 25 May 2021 15:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1621983333; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=lzbKzlmhYe6c5srKVdYQmtPedned1m3oP5RtKOlFgiU=; b=HXUJ0oW0xHLN48gttUFA7JIEALXqm0YMNzcqmiQDk9WgjAYlHtCwlpyDwrHjMOQa NcoCojTLwe4hX+24xeOrzt8txvLYP/p5WjJ0yWNigxA78bdUstRgGiLuWKxHL5bkvAu Nfy5dy0zlWmjngY4Q2w/nztWCHs4YS62Stlbwiyg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_20CD996F-CF4F-4C1C-8BD0-CCF6583BCDF9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 25 May 2021 22:55:33 +0000
In-Reply-To: <>
Cc: "" <>, "" <>
To: tom petch <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.05.25-
Archived-At: <>
Subject: Re: [netconf] netconf-tls wasRe: Summary of updates
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, 25 May 2021 22:55:38 -0000

Hi Tom,

Pruning resolved items below.

> <tp2.0>
> OK, some references.
> Grepping for the string “tp2.0” returns no results.

Oh, I think that you’re trying to be funny, as <tp2.0> identifies your follow-up comments, which may’ve been marked <tp>.   Do you see now how that wasn’t obvious to me, perhaps next time preface with a comment “see <tp2.0> for follow-ups”.  Better, as I and others have been recommended, you should ditch your web-mail client for something that implements normal indentation for replies...

> tlscmn
> tls-ecc
> needs RFC8446
> Why?  8446 refs and defers to 8422, right?
> <tp>
> wrong IMHO; look at the title of 8422 - "Versions 1.2 and earlier"

Okay, added.

> tls-dhe
> needs 8446
> Okay, 8446 obsoletes 5246.
> <tp>
> Right but I think you need both.  The I-D currently highlights 1.2 and mostly ignores 1.3 where I think they should have equal billing and since they are so different, a reference to 1.3 alone is inadequate so my default position is that both 5246 and 8446 are needed.

The previous git-commit has both.

> tls-gcm
> needs 8446
> Okay, but it’s strange that 8446 doesn’t ref/obsolete 5288…I guess because it uses the NIST “GCM” ref instead…perhaps this draft should as well?
> <tp>
> Well where do you stop? As above, I think that every 5246 needs a 8446 alongside it unless one version does not support the functionality but that is as far as I would go.
> identity ciphersuite
> I do not see the 1.3 values from 8446 B.4
> grepping for “ciphersuite” returns no matches…?
> <tp>
> Bear in mind that 1.3 changes everything it can - try 'cipher suite’

Oh, you meant "cipher-suite-base”

This was Gary’s contribution, so I’m not too familiar with it, but I went ahead and added 5 new derived identities (for the 5 cipher suites listed in B.4), marking each with an “if-feature tls-1_3” statement, while also marking all the other derived identities with an "if-feature tls-1_2” statement.

> case psk
> needs Normative References to the two
> draft-ietf-tls-external-psk-*
> "external-psk-guidance” is Informational and "external-psk-importer” while Standards Track, only regards an interface for importing the PSKs into TLS.  It seems that the existing ref to RFC 4279 (which is NOT obsolete) is pretty good, right?
> <tp>
> Disagree.  The cipher suites of 4279 are invalid with 1.3  1.3 sort of does away with PSK except where there has been a full handshake from which a PSK can be derived for resumption.  1.3 imposes limits on the use of a PSK across versions and with different algorithms which is what  I see the two I-D as addressing.

Okay, added.

> Tom Petch

Updates can be found here: <>