Re: [netconf] TLS 1.3 and pre-shared-keys and raw-public-keys (was: More complications)

Kent Watsen <> Wed, 07 July 2021 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32E923A1E9A for <>; Wed, 7 Jul 2021 09:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 6NZTKWpvpzU7 for <>; Wed, 7 Jul 2021 09:45:32 -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 EFFC53A1E99 for <>; Wed, 7 Jul 2021 09:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1625676330; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=IO9StryemtAQD9zWNosrUA8XuM3PLZ9VS68BFPJk5Gw=; b=WvqylTGZ16tKfLdRRETouzpX5Vy/RvQKgN+WF+3wFUXS4IjuMpmg5T25qNyHFDTZ zoGanRjHps4khT7Vwp6D4BWrI6gfEviXJ4btp2yl2GPU3NygprNV26ATvXABef+xk1q WCQ2tHrKDxHwIW9x9Iv9xpOckCCrtNFy7YWbGq7k=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Kent Watsen <>
In-Reply-To: <>
Date: Wed, 7 Jul 2021 16:45:30 +0000
Cc: "" <>, Henk Birkholz <>, tom petch <>
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Rob Wilton (rwilton)" <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.07.07-
Archived-At: <>
Subject: Re: [netconf] TLS 1.3 and pre-shared-keys and raw-public-keys (was: More complications)
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: Wed, 07 Jul 2021 16:45:37 -0000

Hi Rob,

As AD, please advise.  Before the draft-submit window closes, should I:

1) post the suite of drafts with this open issue pending?
2) post the suite of drafts with support for pre-shared-keys and raw-public-keys removed?
3) not post an update to these drafts?

Regarding #2, I don’t think anyone in our WG cares about pre-shared-keys or raw-public-keys.  They were only added by request.  I appreciate us wanting these modules to be useful to groups other than our own, it’s beginning to affect our ability to finish our work.  If the support is removed, it would be removed only in ietf-tls-* drafts (not crypto-types, truststore, or keystore) and thus could be easily added back in by a future effort or proprietary augmentations.

K. // contributor 

> On Jun 30, 2021, at 4:49 AM, tom petch <> wrote:
> From: Kent Watsen <>
> Sent: 29 June 2021 21:48
> [tweaking the Subject line]
> Hi Henk,
> I just realized that I never replied to your question below regarding urgency.
> It would be good to get a high-level response ASAP so that a quick-patch can be made that will pass the eminent SecDir review.
> A more thorough response would ideally be "ASAP" also, but it is the case that this draft will remain open while a couple other drafts go through WGLC, so the hard-stop window is a few weeks out yet.
> <tp>
> On IoT, there is an I-D on this 
> draft-ietf-uta-tls13-iot-profile-01
> which looks comprehensive and includes a statement about a plain PSK-based client but I am not clear that this covers the options.  It does cater for authentication by certificate followed by resumption with PSK with warnings about early data (which may be strong enough for a Security AD) but seems to skate over the case where no certificates are involved, in particular it makes no reference to the two TLS I-D about the use of PSK without certificates.  My understanding is that you need those two I-D to make PSK without certificates work and so the I-D is incomplete.  That apart, I think that it is the sort of TLS1.3 profile that the TLS WG expects to see for every application that uses TLS1.3 e.g Netconf must do something similar one day.
> raw-public-keys are, to me, different, TLS1.3 simply treats them as another kind of certificate (although the UTA I-D does not) and so does not create similar issues.
> Tom Petch
> Thanks,
> Kent
>> On Jun 15, 2021, at 7:53 AM, Henk Birkholz <> wrote:
>> Hi all,
>> a fellow IETF'ler poked me to pay attention to this thread. Sorry for the latency.
>> Hm - dropping PSK support for TLS 1.3 seems to be leaving a bunch of implementations in the IoT space behind that are inching towards migration, currently.
>> How urgent is this? I can certainly massage the current YANG module, but (in theory) I am occupied by another SDO meeting this week.
>> Viele Grüße,
>> Henk
>> On 15.06.21 13:36, tom petch wrote:
>>> From: Kent Watsen <>
>>> Sent: 14 June 2021 15:27
>>> [CC-ing Henk, to whom a question is directed to below]
>>> Hi Tom,
>>>> Top posting a new and different issue.
>>> Thanks for updating the subject line.
>>>> server case psk references ServerKeyExchange and psk-identity-hint neither of which exist in TLS1.3.  The client sends an extension PreSharedKeyExtension which contains a list of identities from which the server selects one as selected-identity for which the identifier is uint16 indexing into the client's list. RFC8446 s.4.2.11.
>>>> The client description also needs amending.
>>>> TLS1.2 was extended to use tickets in this area to aid session resumption; these have now gone and been replaced by this extension.  I would not suggest adding support for tickets.
>>>> As I may have said before, TLS 1.3 is different.
>>> Henk, could you help with these edits?   Support for PSK and raw public key were added to draft-ietf-netconf-tls-client-server per your request and, if memory serves me, didn’t you help me with the YANG update too?   I suppose what is needed is a either a “choice” statement (with cases for 1.2 and 1.3) *or* sibling-container statements (in case it’s necessary both are configured in case, e.g., the client sends one or the other)...
>>> <tp>
>>> Or else drop support for PSK with TLS1.3 at this time because too little is known about it outside the use for HTTP.  I am starting to see I-D about how to use TLS1.3 with application X, even for HTTP,  and I think that such an I-D will be needed for many applications with or without PSK.
>>> Tom Petch
>>>> Tom Petch
>>> Kent