[secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17

Vincent Roca <vincent.roca@inria.fr> Mon, 10 April 2017 14:03 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AA0120046; Mon, 10 Apr 2017 07:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 S0Mpe5Aq7_y8; Mon, 10 Apr 2017 07:03:19 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AF1128BB6; Mon, 10 Apr 2017 07:03:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.37,182,1488841200"; d="scan'208,217";a="268500973"
Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 16:03:16 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ABD052CC-C615-4464-91A5-3687079AF97F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <7B34A968-7AC9-4CBA-9F84-61AB90EDF65F@inria.fr>
Date: Mon, 10 Apr 2017 16:03:16 +0200
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-rtgwg-yang-key-chain.all@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/VDpHOGAglJcIHJK5WrkpeM-BNHU>
Subject: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 14:03:27 -0000

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: ready with nits

** Question: when saying:

        "When configured, the key-strings can be encrypted using the AES Key Wrap algorithm"

   you do not provide any recommendation. I understand it is possible, but is there any good
   reason to recommend it or do you believe the NETCONF access control feature is sufficient?
   Are there environments where recommending it would be meaningful? I'd like to have more
   information.
   This is a bit surprising when I compare with last paragraph where keys are RECOMMENDED
   to be encrypted when stored within network devices.


** Minor comment: I don't see any good reason to separate paragraphs 2 and 4.


Other comments:

** section 1.2: it says:
        " o  Brackets "[" and "]" enclose list keys."
   There may be a confusion with the term "keys" here (i.e., something different from
   a cryptographic key).

   For instance, in section 3.3:
        |  +--rw key-chain* [name]
   name is not a cryptographic key.


** section 2.2: there's something I don't understand. It says:
    3.  When the send lifetime of the new key becomes valid, the network
        devices within the domain of key chain will start sending the new
        key.

  I have the feeling you mean that this new key will start to be used for transmissions
  (instead of "start sending the new key"). Did I misunderstood something?


Cheers,

  Vincent