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