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

Kent Watsen <kent+ietf@watsen.net> Mon, 24 May 2021 23:16 UTC

Return-Path: <01000179a0aa5d37-4810234e-8db2-434d-b8fa-780c1648955a-000000@amazonses.watsen.net>
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 B3AED3A10FA for <netconf@ietfa.amsl.com>; Mon, 24 May 2021 16:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9YgTZ7H2RqF for <netconf@ietfa.amsl.com>; Mon, 24 May 2021 16:16:32 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C891C3A10F3 for <netconf@ietf.org>; Mon, 24 May 2021 16:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1621898190; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=44Lxq8Yuqf3Njq8xZ2mPn4nnkMisQHbab/m+qoQUCOM=; b=dVfbySy/k4gvTb43BaoQmGsU6dYoYhFreRyKjAeY/+KgvH0E/wYCdL/z38bJ3oeh W3W+CMFeuszrhXGUSXUfPkn2fG1KpxdHI9mB/6kMvYTPUomoYfc30JdcU0SU8v4M0qD lSKigZux+F2iPS41itx6KAoZBQqFIkYDXybu6AL8=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <AM7PR07MB6248FF0E1E5A053D4FA2BDC4A0299@AM7PR07MB6248.eurprd07.prod.outlook.com>
Date: Mon, 24 May 2021 23:16:30 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>, garywu@cisco.com
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000179a0aa5d37-4810234e-8db2-434d-b8fa-780c1648955a-000000@email.amazonses.com>
References: <0100017980c49236-7975b99d-b591-4da2-a118-f6598517c4e5-000000@email.amazonses.com> <AM7PR07MB624835D8BE54144D97221817A02B9@AM7PR07MB6248.eurprd07.prod.outlook.com> <010001798c0d947e-4d2d14f5-9f0e-450d-ac99-e18c260f0c2b-000000@email.amazonses.com> <AM7PR07MB6248FF0E1E5A053D4FA2BDC4A0299@AM7PR07MB6248.eurprd07.prod.outlook.com>
To: tom petch <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.05.24-54.240.8.31
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/s30djxj-eckb4JIWY_KvoL4zAVo>
Subject: Re: [netconf] netconf-tls wasRe: Summary of updates
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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, 24 May 2021 23:16:34 -0000

[CC-ing Gary in case he can help]


Hi Tom,


> I still think that the I-D lacks clarity about supported versions.
> 
> Introduction
> TLS Protocol [RFC5246]
> Clearly this is TLS1.2 only
> 
> Yes.   In keeping with the original intention (to reference just the current, not obsoleted, document), this should be updated to RFC 8446.   But I wonder if you think the document should reference all four documents (2246, 4346, 5246, and 8446) and then have DOWNREFS?

I didn’t get what you wanted to do here but, for now, I replaced that reference with this paragraph:

    Any version of TLS may be configured, including
     <xref target="RFC2246"/>,  <xref target="RFC4346"/>,
     <xref target="RFC5246"/>, and <xref target="RFC8446"/>.
     Configuring obsolete protocol versions for use in production
     networks is NOT RECOMMENDED.



> I was all for ditching any mention of 1.1 and 1.0 if only for the extra complication.

By “was all for”, do you mean that you’re no longer?  That is, that “supporting” all versions is fine?



>   I no longer recall where 1.2 differs from its predecessors e.g. extensions incorporated in the base, signature algorithms, and it is probably overkill to find the relevant references for those older versions and adding them to the YANG as well but do think something needs adding in the body of the I-D to the effect that support for 1.0, 1.1 is partial, identity for the version number but not details of cipher suites, relevant RFC and so on.

Would you suggest adding said comment to the above paragraph?



> s.2
> This model supports both TLS1.2 and TLS1.3
> Ah, no, TLS1.2 and TLS1.3 but not TLS1.0 or TLS1.1

Do you mean that the sentence is incorrect because the model does support 1.0 and 1.1?  Perhaps simple remove the sentence altogether in light of the above new paragraph?



> s.2.1.1
> Features
> tls-1_0
> tls-1_1
> tls-1_2
> tls-1_3
> Ah no, it may not support 1.0 and 1.1 but it ........ for them but I know not what.

I don’t understand this comment.



> 2.2
> an example for 1.1 and 1.2 but not 1.3; interesting.

That example is completely arbitrary IMO but, alas, it was created by Gary Wu, who is listed as a “Contributor”, but we haven’t heard from in a long time since...



> Reverse engineering the YANG I find that that 'Version 1.0 is supported', 'Version 1.1 is supported'.

Correct.  All the versions as “supported”; all but 1.3 are NOT RECOMMENDED.  Is this a problem?



> hello-params-grouping
> Only 1.2 is referenced as indeed is repeatedly the case in the YANG modules
> 
> Mmm I dunno!

Again, 1.2 *was* “current” before and so everything just pointed to it, assuming that it is a superset of 1.0 and 1.1?  We could just replace all refs to “1.2” with “1.3” and call it a day, but I don’t know if that would be technically accurate.



> I want the Introduction to set the scene which subsequent sections expand on and that I see as lacking.  Support fot 1.0 and 1.1 would, for me, catering for the different cipher suites that they have.

So we need to define additional ciphersuites for 1.0 and 1.1 or dump support for those protocol versions?



> In passing, I was wrong about public keys.  I misread the statement that only certificates and PSK are supported in TLS1.3, forgetting that certificate(255) is a public key!

Gotcha


> Tom Petch

THANK YOU!

Updates can be found in https://github.com/netconf-wg/tls-client-server/commit/b94588b5a33c0852cfacbc415ca0a626bc1c5763.

K.