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

Kent Watsen <kent+ietf@watsen.net> Tue, 25 May 2021 22:55 UTC

Return-Path: <01000179a5bdc371-b665451f-61d4-4364-9d55-e9369f3adc8e-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 52FE83A11A4 for <netconf@ietfa.amsl.com>; Tue, 25 May 2021 15:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 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_H5=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 CQT35YN9XW42 for <netconf@ietfa.amsl.com>; Tue, 25 May 2021 15:55:49 -0700 (PDT)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2777E3A1192 for <netconf@ietf.org>; Tue, 25 May 2021 15:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1621983347; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CZ2vUbR9ltZjRVVXK6yMk9hKI7h8pSbldM4FvmtX5EI=; b=Yj3Ox9I6LMbH24qn4fgU1jaN1EZaU60EsWOUBfTAU4Ffd1vVJmMO2XJtJQ3dtEJj l3DVoiWPnstRLW/mTGPqTUlqJScAhdYzlTHBXDw2edFoj68N5EmGhyOBCCV7RTGG45Q hUUyhV9HLMJyuh2idsBe3//NLqE3oxnlNSxBd56c=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000179a5bdc371-b665451f-61d4-4364-9d55-e9369f3adc8e-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ABC7608C-F047-440A-B728-B3B056A484B5"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 25 May 2021 22:55:47 +0000
In-Reply-To: <AM7PR07MB624888AD4CB3C09809B22702A0259@AM7PR07MB6248.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "garywu@cisco.com" <garywu@cisco.com>
To: tom petch <ietfc@btconnect.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> <01000179a0aa5d37-4810234e-8db2-434d-b8fa-780c1648955a-000000@email.amazonses.com> <AM7PR07MB624888AD4CB3C09809B22702A0259@AM7PR07MB6248.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.05.25-54.240.48.110
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/mYmR5FMeDfpjwMhBmSR2sP5vVSo>
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: Tue, 25 May 2021 22:55:55 -0000

Hi Tom,

Pruning resolved items below.

> I would still drop 1.0 and 1.1 entirely but see that others disagree.  As things stand, I do think that you need to differentiate between 1.2/1.3 and 1.0/1.1, the former being comprehensively supported, the latter not.  I do not have a good set of words for this but think that you need something in the Introduction to set expectations. You could add more details of 1.0/1.1 but I would see that as a retrograde step.
> 
> Tom Petch 

Intro now says:

   Any version of TLS may be configured.  TLS 1.0 [RFC2246] and TLS 1.1
   [RFC4346] are historic and hence the YANG "feature" statements
   enabling them are marked "status obsolete".  TLS 1.2 [RFC5246] is
   obsoleted by TLS 1.3 [RFC8446] but still is common use, and hence its
   "feature" statement is marked "status obsolete".  All the "feature"
   statements for 1.0, 1.1, and 1.3 have "description" statements
   stating that it is NOT RECOMMENDED to enable obsolete protocol
   versions.

Updates can be found here: https://github.com/netconf-wg/tls-client-server/commit/d2af1d7707095f2ad977b804d0f9e13024489ab4 <https://github.com/netconf-wg/tls-client-server/commit/d2af1d7707095f2ad977b804d0f9e13024489ab4>

K.


PS: below are other comments from my previous reply.   Some are still open in my mind, but otherwise will be considered dropped.


>> 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.
> 
> 
> 
>