From nobody Tue Dec 22 16:35:46 2020 Return-Path: <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@amazonses.watsen.net> 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 656D23A1375; Tue, 22 Dec 2020 16:35:44 -0800 (PST) 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Mj1VqA6cCeAF; Tue, 22 Dec 2020 16:35:43 -0800 (PST) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5E53A1374; Tue, 22 Dec 2020 16:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608683733; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=QiNBCV7g484bZ7js2oMBN8//inWODaleTMeeVQC2WRc=; b=HDTcEue1gfAQPhfPtqWhInDYWdW3cpS6wVG7mOYAWvKnmr8L7v7l9PVho0KM/NC/ fLQbPh8ZD4hpUBWM15sp/3zE+rIl2IluQAobyGyg/A4ErUoXHs4kyEPYth39ssrxGaw iODBVW6EePE8v4GQYOYnNQ0ZSBrUkKHuNehn+Ctw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> Date: Wed, 23 Dec 2020 00:35:32 +0000 Cc: secdir@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-trust-anchors.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@email.amazonses.com> References: <160107496501.14047.597283542214697710@ietfa.amsl.com> <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> To: Yoav Nir X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.23-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 00:35:44 -0000 Hi Yoav, I finally found some time :sigh: ;) Please see below for responses to your comments. Kent > On Oct 2, 2020, at 7:20 AM, Kent Watsen wrote: >=20 > [-last-call] >=20 > Hi Yoav, >=20 > Thank you for your review! The takeaway for me is that some = clarifications are needed, but otherwise the draft is fundamentally = okay. I will post an update, or perhaps just a GitHub commit, for your = review, when I get a chance. That said, my getting a chance will be = delayed as I have a major engagement I need to focus on now. This email = is just to let you know that your review has not been forgotten. >=20 > Thanks again, > Kent >=20 >=20 >> On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker = wrote: >>=20 >> Reviewer: Yoav Nir >> Review result: Has Issues >>=20 >> 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. >>=20 >> The document defines a YANG model for managing a trust anchor store. = It allows >> two kinds of trust anchors: certificates and raw public keys. = However, >> certificates are not just containers for public keys. Certificates = include >> attributes about key usage, path constraints and name constraints, = all of which >> constrain the ability to use the public key, and are relevant for = trust >> anchors. As far as I can tell the document does not include any = attributes to >> equivalently constrain the use of the raw public keys. If the = intention is >> that raw public keys will not be constrained, the document should = state this >> explicitly. Good catch. You=E2=80=99re right that this document is not constraining = the raw keys in the truststore. Looking deeper, I see that the keys are = unconstrained in both the =E2=80=9Ckeystore=E2=80=9D draft and the = common =E2=80=9Ccrypto-types=E2=80=9D draft. It seems like the right = thing to do is to put a Security Consideration note into each draft. = Something like this? 4.2. Unconstrained Public Key Usage This module enables the configuration of public keys without constraints on their usage, e.g., what operations the key is = allowed to be used for (encryption, verification, both). This module also enables the configuration of certificates, where each certificate may constrain the usage of the public key = according to local policy. Thoughts? >> Perhaps this is clear to the people who worked on the document, but = it's not >> clear to me. Are the trust anchors managed with this module supposed = to be >> used to establish trust for the NETCONF or RESTCONF connections? = Section 1.1 >> seems to suggest that it does, but then how is the bootstrap problem = solved? >> How do we establish the NETCONF connection the first time, and if we = are able >> to do that, why do we need more certificates? If the answer is no, = and the >> certificates are to be used by other protocols, then perhaps some = re-wording in >> section 1.1 would help to show this. Currently, it says: "This = document >> presents ... YANG modules that are part of a collection of RFCs ... = define >> configuration modules for clients and servers of both the NETCONF and = RESTCONF >> protocols." Answering your question: Yes, the trust anchors may be used to establish = trust for NETCONF and RESTCONF connections. The trust anchors may also = be used by other models (e.g., other TLS-based protocols), created = outside the effort described in Section 1.1. For the bootstrap problem, Section 3 (Support for Built-in Trust = Anchors) shows how a system may be shipped from a Manufacturer=E2=80=99s = facility with preconfigured trust-anchors. FWIW, the =E2=80=9Ckeystore=E2= =80=9D draft separately defines how a system can be shipped from a = Manufacturer=E2=80=99s facility with preconfigured private keys (e.g., = using a TPM-protected key). You suggest rewording the first paragraph in 1.1. First, I have to = assume you saw the second paragraph, that says that the modules have = been defined to be used by other efforts, so my best guess is: OLD: This document presents one or more YANG modules [RFC7950] that are part = of a collection of RFCs that work together to define configuration = modules for clients and servers of both the NETCONF [RFC6241] and = RESTCONF [RFC8040] protocols. NEW: This document presents one or more YANG modules [RFC7950] that are part = of a collection of RFCs that work together to, ultimately, enable the = configuration of the clients and servers of both the NETCONF [RFC6241] = and RESTCONF [RFC8040] protocols. Please let me know what you had in mind, if something different. >> The security considerations section is OK, especially sub-section = 4.2. Thanks. >> Sub-section 4.1 has the following: >>=20 >> The YANG module defined in this document defines a mechanism called = a >> "truststore" that, by its name, suggests that it will protect its >> contents from unauthorized modification. >>=20 >> Perhaps this is my different perspective, but the name doesn't lead = me to >> expect that it protects its contents. I think that the document = should either >> just suggest that some mechanism to prevent unauthorized modification = should be >> used, or to present such a mechanism in detail. The current text = suggests is >> partially specific by mentioning digital signatures and non-volatile = storage, >> but not explaining where the trust for the digital signature comes = from and >> what policies govern its us: >>=20 >> In order to satisfy the expectations of a "truststore", it is >> RECOMMENDED that implementations ensure that the truststore contents >> are signed when persisted to non-volatile memory, to prevent >> unauthorized modifications from being made undetected. >>=20 >> It is too vague to be a specification, but still unnecessarily = constrains the >> solution space. I think the correct thing to do is to be explicitly = vague and >> to just suggest some mechanism for protecting the content. Agreed. OLD: In order to satisfy the expectations of a "truststore", it is = RECOMMENDED that implementations ensure that the truststore contents are = signed when persisted to non-volatile memory, to prevent unauthorized = modifications from being made undetected. NEW: In order to satisfy the expectations of a "truststore", it is = RECOMMENDED that implementations ensure that the truststore contents are = protected from unauthorized modifications when at rest. What do you think? Thanks, Kent (as editor/author)