Re: [netconf] WG LC for three drafts
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 17 June 2020 10:53 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 441003A094A for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 03:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PkM7hG9zU1IG for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 03:53:32 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB153A0944 for <netconf@ietf.org>; Wed, 17 Jun 2020 03:53:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 554424C1; Wed, 17 Jun 2020 12:53:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Ut_Du1fvZ_HR; Wed, 17 Jun 2020 12:53:29 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jun 2020 12:53:29 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id F21CB20154; Wed, 17 Jun 2020 12:53:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id P5I5RzPiXyuT; Wed, 17 Jun 2020 12:53:28 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7756B200E4; Wed, 17 Jun 2020 12:53:28 +0200 (CEST)
Date: Wed, 17 Jun 2020 12:53:28 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
Message-ID: <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-ooxVS5WL1Y4iCwemVAgc7puX48>
Subject: Re: [netconf] WG LC for three drafts
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: Wed, 17 Jun 2020 10:53:34 -0000
I have reviewed the I-Ds today and here are my comments: * general comments - These drafts needs serious reviews by security domain experts. This all looks reasonable to me but since this is all about security, we need to set the bar high to get things right. - I think the work is in a good shape but the documents need another round of tweaks to get them ready. * draft-ietf-netconf-crypto-types-15.txt - I agree with others that this document lacks introductory material. - Perhaps the title should reflect that this document is not just defining types but also groupings. - The public-key-grouping says that it captures a public key and its associated algorithm but I am not sure how this is done or is the idea that every algorithm requires a different public-key-format? - The asymmetric-key-pair-grouping says that it captures a private key and its associated public key and algorithm but I am not sure how this is done or is the idea that every algorithm requires a different private-key-format? I also wonder how this grouping captures the associated public key. - Do we have to be prepared for alternate cert formats in the future? - The certificate-expiration notification of the trust-anchor-certs-grouping probably needs adjustment; I assume this applies to any certificate the the cert leaf-list. - Is there any semantic difference between trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why do we need two groupings? Same question for trust-anchor-certs-grouping and end-entity-certs-grouping. If there is a semantic difference, perhaps this should be highlighted in the grouping description. - I have not checked the examples. * draft-ietf-netconf-trust-anchors-10.txt - I agree with others that this document lacks introductory material. I am personally not a fan of one sentence sections but that may be just a personal style / preference issue. - The idea that there are groupings that support locally defined crypto keys or references to a centralized trust store really deserves to be explained upfront. Yes, I can reverse engineer this from the definitions, but people who need to decide whether they want to implement this module may not have the time and energy to do this. Notice that the abstract only talks about bags that can be referenced. - How does the storage of user public ssh keys suggested in the example usage section relate to the data model in RFC 7317? - The authors listed on the document and in the yang module are different. - Do we need the truststore-supported feature? We do not have this in other YANG modules. Is the idea to distinguish implementations that only import groupings? Even in this case, should this not be handled by the yang library somehow? - Do the leaf names always look good in instance data? For example, is <truststore-reference> may not be the most descriptive name in instance data. Perhaps it would help to also have examples that show how various groupings are used, not just the bags. - I have to think about the 'copy to running' procedure described in section 3. Perhaps this is the way to go but who happens if things get out of sync? - Why is it useful to define truststore-grouping, i.e., why is this not just a part of the truststore container definition? How are the reference types going to work if you instantiate the truststore-grouping elsewhere? - I have not checked the examples. * draft-ietf-netconf-keystore-17.txt - Looking at the overview figure (that is unfortunately to be removed), I wonder whether trust-anchors should be renamed to truststore as this seems to be the term used by the yang module. - I appreciate the introductory text that this I-D has (compared to the others). - Several pages of yang tree output without explanations is not very helpful. I suggest to break this into pieces and to explain for each grouping when it may be used (or not used). - I am not sure I understand the examples, more precisely, how <keystore-reference>rsa-asymmetric-key</keystore-reference> or <keystore-reference> <asymmetric-key>rsa-asymmetric-key</asymmetric-key> <certificate>ex-rsa-cert</certificate> </keystore-reference> will be interpreted. - What is the informative reference to RFC8342 in the YANG module? - Do we need the keystore-supported feature? See discussion above. - Should the support for encrypted keys be moved to the cryto-types module? Is there a reason why we add the feature to have keys encrypted here? Perhaps this is sensible, I am just trying to check whether this has been given some thought. - Why is it useful to define keystore-grouping, i.e., why is this not just a part of the keystore container definition? How are the reference types going to work if you instantiate the keystore-grouping elsewhere? - I have to think about the 'copy to running' procedure described in section 4. Perhaps this is the way to go but who happens if things get out of sync? What is a system provided cert is exceeding its lifetime (does this even lead to a stream of notifications)? - The text in 5.3 scares me a bit. Migrating root keys may be seen as a bad idea by some. If you have a new device with new root keys, then you better re-encrypt or re-key instead of patching the root key. Or are you essentially saying that encrypted keys should be encrypted with a key-encryption-key instead of the 'root key'? - I am not sure how one implements the 'MUST ensure that the strength of the key being configured is not greater than the strength of the underlying secure transport' nor am I sure that the consequences are really desirable, i.e., I can never move to 'more secure keys' than what the transport currently allows. I think I understand the argument that says a key can't be more trustworthy than the transport used to configure it but I do not think we should disallow upgrade paths. - I have not checked the examples. /js On Tue, Jun 02, 2020 at 04:48:07PM -0700, Mahesh Jethanandani wrote: > NETCONF WG, > > The authors of > > - draft-ietf-netconf-crypto-types > - draft-ietf-netconf-keystore > - draft-ietf-netconf-trust-anchors > > have indicated that these drafts are ready for Last Call (LC). > > This kicks of a 2 week WG LC for the three drafts. Please review and send any comments to the WG mailing list or by responding to this e-mail. Comments can be statements such as, I read/reviewed the document and believe it is ready for publication, or I have concerns about the document. For the latter, please indicate what your concerns are. > > Any reports on implementation status or plans to implement are also very useful. > > Thanks. > > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- Re: [netconf] WG LC for three drafts or two of th… tom petch
- [netconf] WG LC for three drafts Mahesh Jethanandani
- Re: [netconf] WG LC for three drafts Eric Voit (evoit)
- Re: [netconf] WG LC for three drafts Eric Voit (evoit)
- Re: [netconf] WG LC for three drafts Kent Watsen
- Re: [netconf] WG LC for three drafts or two of th… Kent Watsen
- Re: [netconf] WG LC for three drafts or two of th… Eric Voit (evoit)
- Re: [netconf] WG LC for three drafts Mahesh Jethanandani
- Re: [netconf] WG LC for three drafts tom petch
- Re: [netconf] WG LC for three drafts Juergen Schoenwaelder
- Re: [netconf] WG LC for three drafts Salz, Rich
- Re: [netconf] WG LC for three drafts or two of th… tom petch
- Re: [netconf] WG LC for three drafts Kent Watsen
- Re: [netconf] WG LC for three drafts Juergen Schoenwaelder
- Re: [netconf] WG LC for three drafts Juergen Schoenwaelder
- Re: [netconf] WG LC for three drafts tom petch
- Re: [netconf] WG LC for three drafts or two of th… tom petch
- Re: [netconf] WG LC for three drafts Salz, Rich
- Re: [netconf] WG LC for three drafts or two of th… Kent Watsen
- Re: [netconf] WG LC for three drafts or two of th… tom petch
- Re: [netconf] WG LC for three drafts tom petch
- Re: [netconf] WG LC for three drafts Eric Voit (evoit)
- Re: [netconf] WG LC for three drafts Salz, Rich
- Re: [netconf] WG LC for three drafts Kent Watsen
- Re: [netconf] WG LC for three drafts or two of th… Kent Watsen