Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sun, 30 December 2018 00:30 UTC

Return-Path: <kaduk@mit.edu>
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 97EE11294D0; Sat, 29 Dec 2018 16:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu
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 DL6rF3gQXXFS; Sat, 29 Dec 2018 16:30:12 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750127.outbound.protection.outlook.com [40.107.75.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E62B130DC0; Sat, 29 Dec 2018 16:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q2s37zXAtXstiOeIyCDpolwSY2sw0/PrRuAxh+7VEek=; b=RPU2uv1A+83N4wvWjIzEqCEyy9mgUix6FsJeN8POQ8wdYOdsK72Jt6lsP7ZOJUIvomxeh3QCc+cSBvXNPsr9he6Z/5A9ckTKGxL6ZJjzzGyfT3/duE0nZBTxEt0SjibX/9UJi3roN/4polWGyNcmamYORydJS7LeJATYzaUIJG0=
Received: from BL0PR0102CA0060.prod.exchangelabs.com (10.167.241.101) by BN6PR0101MB2947.prod.exchangelabs.com (10.174.86.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Sun, 30 Dec 2018 00:30:08 +0000
Received: from DM3NAM03FT058.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by BL0PR0102CA0060.outlook.office365.com (2603:10b6:208:25::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.20 via Frontend Transport; Sun, 30 Dec 2018 00:30:08 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT058.mail.protection.outlook.com (10.152.82.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sun, 30 Dec 2018 00:30:07 +0000
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wBU0U3hK015579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 29 Dec 2018 19:30:05 -0500
Date: Sat, 29 Dec 2018 18:30:03 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Kent Watsen <kwatsen@juniper.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20181230003002.GC57547@kduck.kaduk.org>
References: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com> <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(39860400002)(2980300002)(51914003)(51444003)(189003)(199004)(40224003)(53234004)(75432002)(26826003)(966005)(33656002)(1941001)(106466001)(23756003)(53416004)(4326008)(229853002)(88552002)(2870700001)(478600001)(2906002)(6916009)(54906003)(5660300001)(246002)(476003)(486006)(345774005)(186003)(36906005)(8676002)(126002)(426003)(4744004)(956004)(446003)(11346002)(50466002)(9686003)(86362001)(104016004)(7696005)(14444005)(76176011)(53946003)(356004)(55016002)(26005)(316002)(786003)(6306002)(106002)(1076003)(58126008)(336012)(47776003)(6246003)(305945005)(8936002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR0101MB2947; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT058; 1:xWcOFOb6otorox8tuF04kaGMcQFwYBxV4GSnojJddcrne4z+lBoDj7sSgemf8u1v62DbdDlOo0jMWC95+kN6u20PgNStHBBkGy8S8Q02nTWxohGTiyNIeag7E/MlJzfL
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 963da21a-bac7-4204-1725-08d66dedf3dd
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:BN6PR0101MB2947;
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 3:/Gr+W6SJkwvPNdnQ0XegVmltzZghbQsPiR857LpZrhJPGt2eItTBjw1ACFubJNuToVgTpAI06q6nHDVOPICW/zjDn2gofoeXHdt8DK2mK0JOPPQtHnBeYM3w80vj0pZhc/MSR2/7k4JTVF7MnU2nykHqzFU7OxUEJv5zDrARqMDqygoEcHboTpDkhV/1zYmGjVMiAo8YCl5NLhlGRyJF2dpd2/imauQPcvl18aZoOxLKDflzD91ls4wBfGvSW3OZW59woegiccyH/i0coSW4x2vYilh/7WPIy0EMXfGg+QOwJCDYziia/jOBH10w+/uHEuQvY/+gclm66IH37mO6WA==; 25:GGpGAOyBfviGjXXXB44pHWYu0mhonQg5Md9QzPWlf1kWpDs6gEimA9L8Fm5SA1Q7uJB7UqoCeV8hpnYCug21UtjKOLZp3lj2iy5IUPBYRl0ulI8dflTHi9MFHN85Owim2rB4c712Gmtnxx4FWlBhw7o0yBEu/NFkip77/AsueBnRMNwREv+RmCiL4RZ3rdI4kfBOwU7nsXkmTBKw6E9Zal0/RsSR3F1zW9eZ4bjojgPYwWbMVD6IRi40fz4iztFzvsgNQpFK7BjKzY1CegnCYYlCtVP85Lzh0ydmAAXd21GUVEIqIioJZNTrO9h6Rsxqp7xQL7YgzRUuUS3ruxVqDw==; 31:wHo8L3TNSyUHS3+kTLvdPhSSkQU81PmuA5MtTd8dUKZzQ7zBMUJD65IJ+09/UDWmDnC6Qk3YrtJ5xQ4PRgLqFXfbp1x1k0TmFnUO1wC57o1DUC01FCQpQbA3kqTtchqHWzaOgVNDsbL/XEZ9+uEAIjxteAHE3Mbj6h4+2cEXoN6FfX/utasRC+VGNRMqDeX/UpR3++L7Bp+d4hkWGtvgHf3zPOVdrbDlcKP5rilDk1Q=
X-MS-TrafficTypeDiagnostic: BN6PR0101MB2947:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 20:TAby+bK3DDwxSK1r22PgbeNZZ9lOtqGWx0OXqY9QOo9ZGluWfs1PxE+U+j7yyXdUanv5mTZ3ImFs0m7diuIAds//VeR0Mfqt2N2uYxwUseQJH6XPxiHylWQCCL/zyTJks3XXbXXhrzkgIC4XDsVrkJwsYzYO43IVpkM/07h/G8Ceq5GqX3PrigcF0jwGCzrdXBnTOB8ccWHZJdb/2YFhv+Els5yoo6s3coF1502G7S9OUpeY00AKXTXdbd+1XOWzlJmGanhSN0uOR7pFxYmEryW8us1Ae/vLS4UiMZEbHCay5ZpHMk0pgYlVCfLvOhQaL+Uzbwz4asQGDHp51tBEirzb1UGeQBcrrVYrnGSpAeiQwlprFnX7nTIai4glcQcdKHqpMNautdup+AlyHArwJe9wXDUtdpAz8GA891Pu26sNDU8MVaoSKFIsZWEzrR3qNv5GXpjr1z91jYCA6MWBf3UpNtxQeTsWc8xlqHDs7sobbEW+SxiMT45UH6Y2zkhL; 4:CxoKa4GkNUb5zZGJGaocgyOoCn0bdhORtez6huEhwUn1Ae98JZY+Ua9py8tLIujEK7jUVRjBzi0/lznWu7scLCkNAlRZMSTnJObrplc8YItMeDxzqdpFRa7vRuYQdyN8p/ILlsULAQN5w4LbC0jr3hn6qOFAWmyWnokiDIpzFMx4leqv+VT0hS34pbqQRNa3+u23XIxhh7nMYUPSsOlW3Y45/p/CuAm6eDyss6OXzyrGpA5e3JezaVMxevrymwgdDActcH2fMy17UOVRy4HMLg==
X-Microsoft-Antispam-PRVS: <BN6PR0101MB294743DF2FA5B68639A05B36A0B10@BN6PR0101MB2947.prod.exchangelabs.com>
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220055)(2401047)(8121501046)(93006095)(93004095)(3231475)(944501520)(4982022)(52105112)(3002001)(10201501046)(6041310)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BN6PR0101MB2947; BCL:0; PCL:0; RULEID:; SRVR:BN6PR0101MB2947;
X-Forefront-PRVS: 0902222726
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN6PR0101MB2947; 23:370LgdUFSQVwIRVH0nPNIJvSBmg9jYrAC1UmP?= =?iso-8859-1?Q?wD1D6tLZSjDJ9kucJoIg8PrWMQwr9XvVmHu1k+QaM51/yFeEDFku/J09/H?= =?iso-8859-1?Q?iphBuCu7ACoXLffHJ2pvtxgLDob8m4xRYKLFtrllk8j6WxrlZcDvq/NVqW?= =?iso-8859-1?Q?zJkZSM0zoIepoa6AxaUDO1Ytg+BOnQ5Dd0V7IX3PDtr9pGWtt48ePIk7sc?= =?iso-8859-1?Q?LSOD6KxsilGx8OiuXr5t8Wirnqisn2sZp+kfJPjofuHQs5BmUNywBlWdro?= =?iso-8859-1?Q?lgrr98mRh33LkDrhnH5zOMK52MrgyN2AuSvG8TlyPBm/tAU+o/9W5YyGue?= =?iso-8859-1?Q?2HcVx6IfXXttU99QG5jdRx5iF8Bithu4mkAY+i/7GKx5gMLKf9eZtyOEyW?= =?iso-8859-1?Q?NtKdRA7R1ihVKMEybaIVFOqTFAdhwgi40JIgF3fJjLL5SDVRxEhyxPKAuy?= =?iso-8859-1?Q?LIHJkpqeVCcJVMc7Qep+aVTIdWBpCtDtCCdnzQi2E8xFzK6kbO3B9YigQy?= =?iso-8859-1?Q?SZaV1+TH1YPvsPyc3qrCnKzqnmdU6kMPHqC56EMc3XilqhaAHS8dLe6Xi6?= =?iso-8859-1?Q?zBrlXDpjw8LAKRIb7+BUL124BLOjDRkNPJed7iqiRwbr9ekvxnVx74tu4t?= =?iso-8859-1?Q?pmjIDqT7GQJCZVDBjB27wIZEKfFLxCv9X53e5pZqoo0xNVGGAbzSkQqhYH?= =?iso-8859-1?Q?TsinSLjL5kVViKRUASPkUnYv/F1r7uUcHQb1TSSH5B/KNBPYfhCEbrJeus?= =?iso-8859-1?Q?akqK8IMs83u37ITWr7F1EZZCYbdc2zwDXT7dAQzLoPkE+Zb378rmIDX42p?= =?iso-8859-1?Q?ucjbZWp6bLK5i6hR/iqqlulyr2eS8qjEGMxgmXw+ftv46lP3cZ7f6aFlyb?= =?iso-8859-1?Q?7QAWZ8CtKrsIL/jxyDLfDy1cHLfbAkGF/jAW+MFwV3idHdZETwnDjsBK2X?= =?iso-8859-1?Q?BhQRtLScTXBdvHbboqTy/+X8FIYYsS11yNaNgtSkl1KxBafu1Wbael1cLA?= =?iso-8859-1?Q?jLiA8hhILI/9TLoitzoaRLy3SGDfgNe2aRoH2t1Jm4jUYXIIlqfTRiM4KF?= =?iso-8859-1?Q?RGK4wJQxV4WQoIBG0TLHVAPrxFHbrGYFUaheQqN+aOyIRlVYy/qlGOzR2h?= =?iso-8859-1?Q?DtpytCFVbu4OcUeVobVFjd/6ky12pPkKTCLqb7UczlXinPh0OOaiGdLjSI?= =?iso-8859-1?Q?vE+w3fHcQ7VAJis0/EJVkOta07LC/kNGkRohqlYfeXFDLR9LLShrkjFCO7?= =?iso-8859-1?Q?jDjYcBHsFE/Mpg0xuj09lcKff94GP3wU14LdNbQl8xdmoVIwRyo7rV0iwa?= =?iso-8859-1?Q?5TBwSRbD0PwRntJXGivEMUSHownJ4YHRYiwmPbHMiz380iS5gQhcfCE8fS?= =?iso-8859-1?Q?6xiAH8fc5OcFe+/5Fy/N38HK9T+Hx1K/LJd7qa8fwaIyWnSPY0GBWZqCIS?= =?iso-8859-1?Q?DQ3pj00ZZkxixXUkbHZifBHdUj7rAkKVMhJaQZcLd/mbjbxmlDZRyin72e?= =?iso-8859-1?B?dz09?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: z0dPxVyUnvo3DDu8LbaSIj17V5lZokubcVVjvEpD/iey1dK6nEOO2/8xY/77OU7BntVZ9b418PlPmMPNJKWdOfBIw0HHwFUdR6c54DuF9IPQZ9hi/RtmAePrNtbR+801vI59K2Fn5IqAajV8qw0NoWYBf9iTNHApWTicwATApMPSWe+AwcryLIiDY9vMxQX6wEvDHRjealhACFAAe95rztKEfNqEeruN4qzU4xEYoJOxpHyhwFdkb90yoIJ9TgijImnavNCsZw4GvIiMBHWSUphaYFdOuE3b7kgxqBuiwRD76B5r7+JSUYrflCxdsaZV
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2947; 6:vV8TjKGnxLXH0v303u+aKGnUQNRFgg4C910UeUCEeFrNGP10b+RjypT+Q9XRBWuG8p6LvYRzWpowzi8ohLJt1XKizBJA+GBv1WfzyCnr4Qf2Jg4pWEwKY11X/OQ1QQIPBhYKgHKcMD5vprnWU1JUgRDB+LJesKcBx4Q1UCl7sUwMhC1fitum4MLlEJ5kbUcFI+NtT95KT2HuIuzF/XcE+NblKek4LZPk1Nm3tPeEACrYTrUfF7gFFMXXQVeTKVSldiakznmk2tdt/di7Kk3AqgWYG4Ksd50rnZvqb2HXzcZEBsEHfHNoNjuRPmffEhfoiS+d+mShDujFrV29MqMOhdyM5z6ztXCKM+7d22QS/RTDlg/flYWwwKU0lefh4YukBqPyPzkl+IlB9uDsF4uL0Ho1Y9Va3bLizf7XrTL6lfpdnAHMWgu2brbkBkNBeVGMrCJ03k6JAturWZUlMu1Jzg==; 5:gAJGpYpkHHTrThNFScSvsMSey2/K/GqLamsVCPjttVHc8KxlmX3HNS7Q3as6V13rRA267bfome9hkgmRly8wN5TuMfwaeV0whjjJWmQ9gcaVJ4MsSV+h6VrYAHhlzDBOomtbec2NvFp7+sd0nM0L7eqqg8Zm7/r+tS3tNnQv4Ac=; 7:vs8eUfxKyuHYFcQIxR7v0+usnk7m+UiJFUailHcMeitHkcPprfNTByU7YHF9gNWdkTSXjsE7NkdtAgp17JeIpJEO8KVGCX2TqzEA9W9yYSBO+XgALLMifuJPTXEoqlgQPOktqGQZzPu/I+dDRtcP1A==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Dec 2018 00:30:07.8502 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 963da21a-bac7-4204-1725-08d66dedf3dd
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR0101MB2947
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9buj14VpmEkYgWMNxgY_Ib3eJXA>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing 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: Sun, 30 Dec 2018 00:30:16 -0000

Hi Kent,

Now that I'm mostly back from vacation+holidays, let's get back to this...

On Sat, Dec 08, 2018 at 02:46:11AM +0000, Kent Watsen wrote:
> Hi Benjamin,
> 
> Thanks for your review!  See below for responses.
> 
> It took me quite some time to compose this response; I can only imagine
> how long it took you to compose your message.
> 
> For when I write "Fixed", or otherwise indicate a change has been made,
> unless stated otherwise, I mean to say that the changes are in my local
> copy (not yet in a published update).

Understood.

> Kent // author
> 
> 
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > First off, thanks for this clear and considered document and design; it
> > really lays out the scenario of applicability and the functionality quite
> > well.  I just have a couple lingering places that we might want to nail
> > down a little bit tighter...
> >
> > (1) SSH key formats
> >
> > The module in Section 7.3 says:
> >
> >           leaf-list ssh-host-key {
> >             type binary;
> >             description
> >               "The binary public key data for this SSH key, as
> >                specified by RFC 4253, Section 6.6, i.e.:
> >
> >                  string    certificate or public key format
> >                            identifier
> >                  byte[n]   key/certificate data.";
> >             reference
> >               "RFC 4253: The Secure Shell (SSH) Transport Layer
> >                          Protocol";
> >
> > but RFC 4523 Section 6.6 says:
> >
> >   The key type MUST always be explicitly known (from algorithm
> >   negotiation or some other source).  It is not normally included in
> >   the key blob.
> >
> >   Certificates and public keys are encoded as follows:
> >
> >      string    certificate or public key format identifier
> >      byte[n]   key/certificate data
> >
> > How is the key type known for the SZTP usage?
> 
> Good catch.  The fix here is to mimic RFC7317's "authorized-key" list.
> That is, convert "ssh-host-key" from a "leaf-list" to a "list"
> containing the extra "algorithm" node.  This fix is here:
> 
> https://github.com/netconf-wg/zero-touch/commit/7a33c418f733aebcd95f2c91c4e9abbccfd362e4

Sounds good.

> 
> 
> 
> > (2) Privilege escalation by design
> >
> > There's text in Section 2.1 (and, really, throughout) that indicates that
> > a device being bootstrapped should allow a trusted bootstrap server to
> > behave as (i.e., supply) a trust anchor for verifying a different service.
> > In some sense this is elevating an EE cert to a CA cert, and I had hoped
> > to see some discussion of this escalation in the security considerations.
> > (Same for the owner cert, though there's a stronger argument that the 
> > owner should be considered fully privileged here.)
> 
> Correct, "redirect information" from a trusted source should contain a
> trust-anchor certificate (actually, a CMS containing a chain of certs).
> 
> Yes, the device's trust in a TLS trust anchor cert (e.g., provided via the
> manufacturing process) is used to trust the EE cert for a bootstrap 
> server that returns a new trust anchor cert, enabling the device to 
> pin the new TA cert for subsequent EE cert validation.  
> 
> This is similar to a CA in that a chain of trusted certs is formed, but
> it isn't quite like a CA cert, in that the EE cert doesn't itself sign
> the new TA cert; it only signs that transport used to convey the TA cert.
> 
> Regarding the owner cert being similar, I think you mean that the 
> ownership voucher [RFC 8366] is similar, which is true.  In this case,
> the device's trust in a trust anchor for voucher-signing certs (e.g., 
> provided via the manufacturing process) is used to trust a specific
> signing cert for a voucher, which encodes a new trust anchor cert 
> (the 'pinned-domain-cert'), which is, in fact, the issuing CA for
> the owner certificate.
> 
> Okay, so we have these two things.  In both cases, trust anchors are 
> conveyed via trusted mechanisms.  Do you want me to add a Security
> Consideration saying this?  
> 
> I somehow thought this concept was fairly common, is it not done 
> elsewhere?

It is fairly common, but it is probably still worth describing the security
properties of the protocol exchanges, here.  (In that a compromise of the
initial interaction can result in compromise of all subsequent
interactions, just as for trust-on-first-use.)

> 
> 
> 
> > (3) Nonce length
> >
> > Section 7.3 describes the nonce leaf:
> >
> >         leaf nonce {
> >           type binary {
> >             length "8..32";
> >
> > There is probably some discussion to be had about the minimum nonce
> > length (not necessarily in the document itself).  Do you have a 
> > pointer handy to previous disucsions or do we need to have it now?
> > (I do see that this is just following RFC 8366, so hopefully this
> > is an easy question.)
> 
> 
> I sent email to my RFC 8366 co-authors, as they were behind setting
> this min nonce length.  I have yet to hear back from them, but will
> let you know when I do.

[covered in separate thread]

> 
> 
> 
> > (4) OPTION_V4_ZEROTOUCH_REDIRECT repeated instances
> >
> > (In Section 8.1.)
> >
> > I think I may just be misunderstanding things here, but aren't
> >
> >   As the list of URIs may exceed the maximum allowed length of a single
> >   DHCPv4 option (255 octets), the client MUST implement [RFC3396],
> >   allowing the URI list to be split across a number of
> >   OPTION_V4_ZEROTOUCH_REDIRECT option instances.
> >
> > and
> >
> >   The DHCPv4 server MAY include a single instance of Option
> >   OPTION_V4_ZEROTOUCH_REDIRECT in DHCP messages it sends.  Servers MUST
> >   NOT send more than one instance of the OPTION_V4_ZEROTOUCH_REDIRECT
> >   option.
> >
> > in conflict about sending more than one instance of
> > OPTION_V4_ZEROTOUCH_REDIRECT?
> 
> Yes, these statements appear to be contradictory.  I asked my co-author,
> Ian Farrer, our local DHCP expert, to answer this question.  I think some
> word-smithing is needed to convey that a "singleton" option may be split
> into pieces.

If memory serves, this was resolved in a different AD's ballot thread.

> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Should we consider recommending AuthEnvelopedData throughout instead
> > of just EnvelopedData?
> 
> I don't think this is necessary as 1) the decrypted data can be tested
> to be a well-formed CMS and 2) using SZTP to cause the device to act as a
> decryption oracle doesn't work well, if at all, as the decrypted text
> isn't subsequently made available.
> 

I'm not sure that (2) is relevant, but (1) and being a SignedData ought to
be enough.  Thanks for thinking it through with me.

> 
> > TLS and CMS are probably good enough about adding context in their
> > signatures (well, provided modern versions are used) that we don't
> > get too much heartburn about reusing the same key directly for both
> > zerotouch [artifact] decryption and TLS client certificates, but 
> > it's generally the sort of thing that we frown upon.
> 
> Understood, which is why the last paragraph of Section 3.4 (Artifact
> Encryption) says "This [encryption] certificate MAY be the same as 
> the TLS-level client certificate the device uses when connecting to
> bootstrap servers.".  The draft is going out of its way to say that
> this is okay.  This is necessary, in part, because devices tend to
> have only a single IDevID certificate, and hence it tends to be used
> for both digitalSignature (for when used as a TLS client cert) and
> keyEncipherment (for decrypting the zerotouch artifacts).  The draft
> also leaves open the possibility to use distinct certificates for
> each purpose.  Perhaps a Security Consideration for this would be
> good?  [But given that these are distinct/separate uses, with no
> leakage between (AFAICT), then maybe not needed?]

I would suggest (recalling that this is a non-blocking comment) adding some
text that this does allow for reuse of the private key to make different
types of signatures, but there are not any known ways to cause a signature
made in one context to be (mis)interpreted as valid in the other.

> 
> 
> > I a little bit wonder if we want references for TLS and/or HTTP client
> > authentication.  Section 2.5 of RFC 8040 might be enough (though it is
> > of course not citing TLS 1.3).
> 
> This draft's use of TLS and HTTP authentication is exclusively for
> RESTCONF (RFC 8040).   I'm generally hoping to just reference that
> RFC and let it speak for itself.
> 
> Correct, RFC 8040 does not cite TLS 1.3 explicitly, though TLS 1.3 is
> allowed, as Section 2.1 says:
> 
>    RESTCONF does not require a specific version of HTTP.  However, it 
>    is RECOMMENDED that at least HTTP/1.1 [RFC7230] be supported by all
>    implementations.
> 
> BTW, does this comment regard Section 9.6?  

Section 9.6 is about making sure the client does not send sensitive data to
an unauthenticated server, which is not limited to the data in the
certifcate; my comment here is more about the mechanics of the client
authenticating itself to a server for the server to make authorization
decisions (admittedly, I did not mention "authorization" prior to now, so
my apologies for being unclear).  Client authentication is mentioned
directly or in passing in at least sections 5.1 (which does mention Section
2.5 of RFC 8040 already) and 5.3 (ditto), as well as 9.6.

> 
> 
> > (Are there generic RESTCONF internationalization considerations?
> > I see 8040 say "just use UTF-8", but is more needed?)
> 
> I'm not aware of any problems here.  No RFC 8040 errata has been filed.
> Is there something in particular you're thinking about?

Nothing in particular, no.  

> 
> 
> > Section 1.2
> >
> >   Network Management System (NMS):  The acronym "NMS" is used
> >       throughout this document to refer to the deployment specific
> >
> > nit: deployment-specific (with hyphen)
> 
> Fixed (as well as the instance in Section C.2)
> 
> 
> 
> > Section 2.1
> >
> > Does RFC 8340 require a "ro" (or similar) to appear in the tree
> > diagram? (Both here and in ยง2.2.)
> 
> No, because these are "yang-data" structures.
> https://tools.ietf.org/html/rfc8340#section-2.3.

Ah, thanks for the pointer -- learn something every day.

> 
> 
> > Section 3.2
> >
> > Do we want to impose any ordering requirements on the certificate
> > chain (e.g., owner cert must come first, each cert SHOULD certify
> > the one immediately prior to it, etc.)?
> 
> The owner certificate is encoded using a CMS SignedData structure.
> SignedData is defined in RFC 5652, 5.1.  The "certificates" field
> is of type "CertificateSet", defined in Section 10.2.3 as a "SET OF",
> which is defined in ASN.1 as an unordered collection.  So, ordering
> is not possible.

Okay.

> 
> 
> > Section 3.4
> >
> > Thank you for including the motivating text about sign-then-encrypt.
> > I do wonder if it's worth saying anything about why the well-publicized
> > security risks of mac-then-encrypt do not apply.  (The authors of
> > draft-campbell-sip-messaging-smime probably already have some text
> > that could be used, but it doesn't seem to be in the public view yet.)
> 
> Are you referring to the padding oracle attack?  As mentioned above, the

Right.

> solution presented in this document doesn't lend the device to being a
> very good decryption oracle.  I suppose the fix would be to add to this
> section (or the Security Considerations section?) something like:
> 
>   This document specifies the encryption of signed objects, as opposed
>   to the signing of encrypted objects, as might be expected given well-
>   publicized oracle attacks (e.g., the padding oracle attack).  This
>   document does not view such attacks as being feasible in the context
>   of the solution because i) the decrypted text never leaves the device
>   and ii) the solution does not differentiate between a "bootstrap-error"
>   cause by a decryption failure versus a failure occurring when parsing
>   the decrypted text.

That works for me, thanks.  (But feel free to leave it out if you don't
think it's adding value, too.)

> 
> 
> > Section 4.1
> >
> > Mounting all filesystems found on removable devices can be a security
> > risk, with intentionally malformed filesystem images causing system
> > compromise in some cases.
> 
> Is the concern the mounting of *all* or *any* filesystems?  It seems 
> that even if there were just one filesystem, it could be intentionally
> malformed.  Are you hoping to see a Security Consideration for this?

The concern was any, thanks for figuring out what I meant.
Thinking about this again after the long gap, it seems a pretty generic
consideration, so it's unclear that Security Considerations text in this
document specifically would be particularly helpful.

> 
> 
> > Section 4.2
> >
> > I agree with Adam about registering "zerotouch" (and the name is
> > perhaps overly generic?).
> >
> > I'm also not sure I properly understand the "zt-info"/zt-* TXT
> > records' usage; would they need to be registered akin to
> > draft-moonesamy-dnsop-special-use-label-registry?
> 
> First, regarding the term "zerotouch" being perhaps overly generic,
> I have somewhat felt this way for a while.  One thing that could be
> done fairly easily is to more the bulk of the "zerotouch" references
> to "sztp", the acronym given throughout.  Admittedly, what SZTP
> stands for isn't tremendously better, but I think that it is
> generally better than just "zerotouch".  Thoughts?

SZTP does seem better than just "zerotouch" to me, all things considered.

> Second, I am not a DNS expert, do you know who we can discuss
> such things with?  That said, I guess our idea was to use TXT
> records like RFC 1464, where the TXT value itself has the form
> "<attribute name>=<attribute value>", in which case it doesn't
> seem to need IANA registration?

Please correct me if I'm wrong, but I think this issue was already covered
in a different AD's ballot thread.

That said, the addition of <serial number>._zerotouch.fqdn in the -26 seems
to indicate that mention of draft-ietf-dnsop-attrleaf is appropriate, if I
remember correctly how that works.

> 
> 
> > Section 5.3
> >
> > This is the first time we talk about "serial number" as device identity;
> > maybe a forward-reference is in order?
> 
> I'm unsure what the forward reference would be to.  However, I think that
> we could add "serial number" to Section 5.1 (Initial State), as a new
> first item in the <read-only storage> box.  Would that be better?

It looks like -26 added some text relating "serial number" and "device
identity [certificate]", so let's call this OBE.

> 
> > Does the device have any reason to track whether the incoming artifact is
> > encrypted (whether at the CMS layer or the transport layer)?  I can't think
> > of one, but sometimes this is useful information in other settings.
> 
> I also cannot think of a reason.  That the incoming CMS is encrypted has
> no bearing on device's processing logic.  This is expected, given that the
> device's public key is, well, public, and therefore access to it has no
> special meaning.  Note that encryption here is used to ensure privacy, as
> only the device can decrypt/access the data.

Agreed.

> 
> >   If the zero touch information artifact contains onboarding
> >   information, and trust-state is FALSE, the device MUST exit the
> >   recursive algorithm (as this is not allowed, see the figure above),
> >   returning to the bootstrapping sequence described in Section 5.2.
> >   Otherwise, the device MUST attempt to process the onboarding
> >   information as described in Section 5.6.  In either case, success or
> >   failure, the device MUST exit the recursive algorithm, returning to
> >   the bootstrapping sequence described in Section 5.2, the only
> >   difference being in how it responds to the "Able to bootstrap from
> >   any source?" conditional described in the figure in the section.
> >
> > Does this "either case" refer to just the processing of onboarding
> > information, or the exit vs. attempt to process cases?  (I assume the
> > former, but perhaps some editorial work is in order.)
> 
> Your intuition is correct :)   How about this:
> 
>   OLD:
>     In either case, success or failure, ...
> 
>   NEW:
>     Whether the processing of the onboarding information succeeds
>     or fails, ...

SGTM :)

> 
> 
> 
> >   If the zero touch information artifact is signed, and the device is
> >   able to validate the signed data using the algorithm described in
> >   Section 5.4, then the device MUST set trust-state to TRUE; otherwise,
> >   if the device is unable to validate the signed data, the device MUST
> >   set trust-state to FALSE.  Note, this is worded to cover the special
> >   case when signed data is returned even from a trusted bootstrap
> >   server.
> >
> > Having read Section 5.4, I'm still unsure where the special handling
> > for this special case is described.
> 
> There is no special handling per se but, the point that is trying 
> (perhaps ineffectually) is that, if signed-data is received from a
> trusted-source, validating the signature is all that matters, that
> the source was trusted becomes irrelevant to being able to validate
> the data.  Makes sense now?  Does it need to be reworded?

It does make sense now, and I don't think it needs to be reworded -- thanks
for the extra explanation.  (I was mostly concerned that there was a
special case that I wasn't finding in the text, but the existing text
describes exactly what to do, so it's alll good.)

> 
> 
> > Section 5.5
> >
> >   Processing redirect information is straightforward, the device
> >   sequentially steps through the list of provided bootstrap servers
> >   until it can find one it can bootstrap from.
> >
> > nit: I think this is a comma splice.
> 
> Changed to a semicolon.
> 
> 
> 
> > Section 5.6
> >                                                Regardless the
> >   reporting-level indicated by the bootstrap server, the device MAY
> >   send progress reports beyond the mandatory ones specified for the
> >   given reporting level.
> >
> > nit: "Regardless of"
> 
> Fixed.
> 
> 
> 
> >   When the onboarding information is obtained from an untrusted
> >   bootstrap server, the device MUST NOT send any progress reports to
> >   the bootstrap server.
> >
> > I'm not sure if I would want a parenthetical "(that is, the onboarding
> > information was authenticated at the CMS layer)", but I would think about
> > adding one.
> 
> How about postpending:
> 
>   ", even though the onboarding information must have been signed and
>    authenticated.  Please be aware that bootstrap servers are recommended,
>    in the last paragraph of Section 9.6, to promote untrusted connections
>    to trusted connections so as, in part, to be able to collect progress
>    reports from devices."
> 
> Too wordy, or just right?

I am prone to being too wordy myself, but that seems just right to me.

> 
> 
> >   The device MUST parse the provided onboarding information document,
> >   to extract values used in subsequent steps.  Whether using a stream-
> >   based parser or not, if there is an error when parsing the onboarding
> >
> > This line makes me consider the scenario where a stream-based parser is
> > used with a trusted bootstrap server and no CMS-layer signature.  At the
> > TLS layer, a truncation attack by the network is possible, and if
> > truncation is not detectable at the application layer, the device could end
> > up misconfigured with neither party aware (unless there's an additional
> > response or something that I'm forgetting about).  I think that for the XML
> > and JSON formats we know and love, truncation would make for a malformed
> > stream due to the outermost scope container, but please correct me if I'm
> > wrong.  There are probably some security considerations to mention w.r.t.
> > any future new encodings of this data model, though.
> 
> The steps are roughly: 
>   a) HTTPS GET an XML/JSON document (the get-bootstrapping-data" response).
>   b) extract the CMS-based artifacts from the XML/JSON document.
>   c) if encrypted, decrypt.
>   d) if signed, authenticate.
>   e) extract the onboarding-information (another XML/JSON doc) from the CMS artifact.
>   f) process the onboarding-information XML/JSON doc
> 
> So here we're at step (f), where the text mentions the possible use of a
> stream parser.  This is rather long after step (a), where TLS truncation
> may occur and, presumably caught in step (b).  This is by way of saying
> that I don't think this is an issue, but interested to hear your response.
> 
> FWIW, the point of this "stream-based parser" comment is to highlight
> that, unlike most all the other progress-types, which seem to reflect
> a serial processing of the steps, the parsing may either be a distinct
> step (e.g., a DOM-based parser) or something that is splayed across all
> the other steps (a stream-based parsed).  In the first case, the all
> the "parsing-*" progress reports (including any parsing-error report)
> are expected to be transmitted before any, e.g., boot-image-* reports
> are sent; whereas, in the second case, the parsing-* reports can be
> intermixed.
> 
> I don't think there is a TLS concern, but perhaps the paragraph needs
> to be reworded?

I think your understanding basically matches mine; I tried to include in my
remark that it would only possibly apply to the case where the predicates
for (c) and (d) are false.  I just plain don't know whether (a)/(b) will
choke if the GET response is an incomplete XML/JSON document.  If it
properly errors out, then there's no concern here, and we should just move
on.  In any case, even if there was an issue, this paragraph would not
really be the place to talk about it -- my comment is only located here
because this is where we start talking about stream-based parsers.  The
errors in question are not necessarily those generated by the stream-based
parser, but can also include those generated at earlier steps.

> 
> 
> >      *  Most steps are atomic.  For instance, when a commit fails, it
> >         is expected to have no impact on the configuration.  Similarly,
> >         if the error occurs when executing a script, the script will
> >         gracefully exit.
> >
> > As a reader it's hard to tell if this is giving guidance to script
> > authors or consumers.
> 
> Is this better?
> 
>    Most steps are atomic.  For example, the processing a configuration
>    is specified as atomic above, and the processing of scripts are
>    similarly atomic, as specified in the "ietf-zerotouch-information"
>    YANG module.

Yes, thanks.  (I think the -26 lost both "of"s, though?)

> 
> 
> > Section 6.2
> >
> > "base64encodedvalue==" is pretty cute, though maybe we could add some
> > trailing numbers to provide different values for the different fields?
> 
> The issue here is that the example documents must be valid (fwiw, they
> are tested each time `xml2rfc` is run).  Previous versions of this 
> document included compete base64 encoding of the real objects, but 
> people complained that it greatly distracted from readability.  To
> address this, the WG agreed to use "base64encodedvalue==" in examples
> to represent YANG "binary" data.
> 
> Is it okay to leave this as is?

This is a non-blocking comment, so by definition my answer is "yes" :)
I mostly just wanted to point out that the examples use the same literal
string to fill in for many different data types -- I agree with not using
"real" examples since they're bulky and not readable in encoded form, but
was just wondering if we could use different short strings to represent
semantically different objects.

> 
> > Section 6.3
> >
> > The YANG module boilerplate is still on the RFC 2119 version of BCP 14
> > (not RFC 8174).
> 
> Fixed. Now both YANG modules read:
> 
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>     "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 
>     "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
>     are to be interpreted as described in BCP 14 [RFC2119]
>     [RFC8174] when, and only when, they appear in all
>     capitals, as shown here.
> 
> 
> 
> > Section 7.2
> >
> > If we're going to say "and receives signed data in the response", maybe we
> > could actually give an example that shows the (base64'd) CMS structure that
> > corresponds to the signature?  Not necessarily the whole payload, but
> > enough to see the outer structure at least...
> 
> See previous response regarding "base64encodedvalue==".  It's tricky
> business.  That said, in a separate "expert review" response from Russ
> Housley, we were thinking to add an appendix section containing all
> the possible ASN.1 structures.  For instance:
> 
>   X. ASN.1 for Various Artifacts
>   X.1. Zero Touch Information
>   X.2. Signed Zero Touch Information
>   X.3. Encrypted and Signed Zero Touch Information
>   X.4. Owner Certificate
>   X.5. Encrypted Owner Certificate
>   X.6. Ownership Voucher
>   X.7. Encrypted Ownership Voucher
> 
> Would this bridge the gap for you?

That would help a lot, thanks!

> 
> 
> > Section 7.3
> >
> > The YANG module boilerplate is still on the RFC 2119 version of
> > BCP 14 (not RFC 8174).
> 
> Yep, fixed along with the fix to the other YANG module.
> 
> 
> 
> >             enum "boot-image-installed-rebooting" {
> >               description
> >                 "Indicates that the device successfully installed
> >                  a new boot image and is about to reboot.  After
> >                  sending this progress type, the device is not
> >                  expected to access the bootstrap server again.";
> >
> > Is this just scoped to the current connection/session?
> > (As opposed to "bootstrap-complete", which probably is a global statement.)
> 
> Yes, just the current scope. how about the following? - or should the last
> sentence be left off?
> 
>               "Indicates that the device successfully installed
>                a new boot image and is about to reboot.  After
>                sending this progress type, the device is not
>                expected to access the bootstrap server again
>                for this bootrapping attempt.  The device may
>                access this bootstrap server after rebooting
>                and restarting the zerotouch bootstrapping
>                process.";

Probably the last sentence is not adding anything useful.

> 
> 
> >   container trust-anchor-certs {
> >   [...]
> >               The CMS MUST contain only a single chain of
> >               certificates.  The device's end-entity certificate
> >               MUST only authenticate to the last intermediate CA
> >               certificate listed in the chain.
> >
> > I'm not sure whether "authenticate to" means that the CA cert directly
> > certifies or is the trust anchor.  Could we maybe use language like
> > "directly certifies the [next|previous]" certificate?
> 
> This text is trying to say that the "last certificate" is the issuer of
> the device's end-entity certificate.  More generally, it's trying to say
> that there are no superfluous certificates in the CMS.  Perhaps:
> 
> NEW:
>                The CMS MUST contain only a single chain of
>                certificates.  The last certificate in the chain
>                MUST be the issuer for the the device's end-entity 
>                certificate.

That looks wonderful, thanks.

> 
> 
> > Also, the split of references of RFC 6187 for trust-anchor-certs but RFCs
> > 5280 and 5652 for trust-anchor-cert seems unusual, since potentially all
> > three would be relevant for both nodes, if I understand correctly.
> 
> True, but my general goal is to have the "reference" statements support
> the "description" statements.  So, in this case, the parent node mentions
> RFC 6187, hence I put the "reference" for it there.  Does it still seem
> unusual to you?

Less so; thanks for the explanation :)

> 
> 
> > Section 9.1
> >
> > At this point draft-ietf-ntp-using-nts-for-ntp exists, though I don't know
> > whether it's appropriate to be citing it yet.
> 
> How about tacking on this last sentence, and list ietf-ntp-using-nts-for-ntp
> as an Informative reference?
>  
>           Implementations SHOULD NOT rely on NTP for time, as
>           NTP is not a secure protocol at this time.  Note, there
>           is an IETF work-in-progress to secure NTP
>           <xref target="I-D.ietf-ntp-using-nts-for-ntp"/>.

SGTM.

> 
> 
> > Section 9.6
> >
> > There is perhaps some room for discussion of the consequences of the device
> > telling the bootstrapping server whether the device thinks the connection
> > is trusted, in that it gives an attacker information about the target.
> > (Granted, it does not seem like much information, but it might be cleaner
> > to define the semantics of the node as being whether the client would like
> > the server to sign its responses at the application layer, which need not
> > have complete overlap with whether the client considers the server to be
> > trusted.
> 
> Hmmm, I agree with the optics.  Perhaps we could change it to "signed-data-
> preferred"?  Keep in mind that signed-data isn't required, as it would be
> okay for the server to return unsigned redirect information.  It's only if
> the data is onboarding information that it would need to be signed.

That works for me.  (It doesn't seem like a big deal either way, of
course.)

> 
> 
> > Section 9.8
> >
> > Does recommending frequent private key refreshes actually help in
> > environments where revocation is unusable (i.e., by virtue of not having
> > reliable time)?  (If not, perhaps that caveat should be more explicit here,
> > even though it is mentioned in Section 9.1 already.)
> 
> Good catch.  How about adding the last two lines below?
>  
>           Bootstrap server administrators are RECOMMENDED to follow best
>           practice to protect the private key used for any online operation.
>           Use of a hardware security module (HSM) is RECOMMENDED.  If an 
>           HSM is not used, frequent private key refreshes are RECOMMENDED,
>           assuming all bootstrapping devices have an accurate clock (see
>           <xref target="clock-sens"/>).

SGTM.

> 
> 
> > Section 9.10
> >
> > I would suggest also mentioning the (lack of) mitigations possible if the
> > operator does not trust all the pre-configured authorities designated by
> > the manufacturers.
> 
> How about adding the last sentence below?
> 
>           Operators should be aware that this system assumes that they trust
>           all the pre-configured bootstrap servers and voucher signing authorities
>           designated by the manufacturers.  While operators may use points in
>           the network to block access to the well-known bootstrap servers, 
>           operators cannot prevent voucher signing authorities from generating
>           vouchers for their devices.

Perfect :)

> 
> > Section 9.11
> >
> >      revealing (e.g., network topology, firewall policies, etc.).  It
> >      is RECOMMENDED that operators encrypt the bootstrapping data when
> >      its contents are considered sensitive, even to the administrators
> >      of a bootstrap server.
> >
> > I don't understand what is meant by "even to the administrators of a
> > bootstrap server"?
> 
> Here I'm thinking that the bootstrap server may be hosted by a 3rd-party,
> or another group within the operator's organization.  For example, the
> NOC generates the artifacts, but IT admins the bootstrap server boxes.
> 
> Any need for an update to this text?

Even given the above clarification, I'm still having a hard time not
reading the current text as saying that the administrators of the bootstrap
server are making the determination that content is considered sensitive.
Maybe "even with respect to distribution to the administrators of a
bootstrap server" or "even to the point of hiding it from the
administrators of a bootstrap server"?

> 
> 
> > Section 9.12
> >
> > nit: the last word is "revoked".
> 
> Fixed.
> 
> 
> 
> > Section 9.13
> >
> >   Implementations should be aware that signed bootstrapping data only
> >   protects the data from modification, the contents are still visible
> >   to others.  [...]
> >
> > nit: this is a comma splice
> 
> Fixed.
> 
> 
> >                                                         This
> >   information should be considered sensitive and precautions should be
> >   taken to protect it (e.g., encrypt artifact with device public key).
> >
> > nit: I think it's more conventional to "encrypt to" a public key than
> > "encrypt with" one.
> 
> How about "encrypt the artifact using the device's public key"?

Sure.

> 
> 
> 
> > Section C.3
> >
> > We could perhaps recommend ecdsa-sha2-* keys instead of ssh-rsa keys.
> 
> Replaced "ssh-rsa key" with "SSH public key"

Even better

> 
> 
> 
> >   4.  Otherwise, if redirect information is found, the device iterates
> >       through the list of specified bootstrap servers, checking to see
> >       if it has bootstrapping data for the device.  [...]
> >
> > The "it" is perhaps ambiguous; I would suggest "each server in turn".
> 
> Replaced "it" with "bootstrap server"

Sure.

Thanks!

-Benjamin