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

Kent Watsen <kwatsen@juniper.net> Sat, 05 January 2019 03:05 UTC

Return-Path: <kwatsen@juniper.net>
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 3A197130DCD; Fri, 4 Jan 2019 19:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level:
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 UNc1JuZmWPKm; Fri, 4 Jan 2019 19:05:41 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 5FAA31271FF; Fri, 4 Jan 2019 19:05:40 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x05326Ns007756; Fri, 4 Jan 2019 19:05:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=WBjc1fW9JM5hRnjEZXspx1EyIBvxf1Uoo7cL2BXhWdY=; b=xogfC4k5/PA0Z3Ued0+w8XjFG2vQszocJ4kKHaK4LG24iP7cwxk+JyazYfMgNxO0A0eb eSodm0bM2zKL67t6+XP2juWPOaV33PBUpY0dFtUZ5DV31zlmndkQO/tR/koF5ZCwJGpm qlmbp25oDy0Z0okrDdvUykBu7FtCkJRYVS5HbcxuamF7/YjSiqogCReFu6Zw1Mopvc3Q GXYZuXFpVkAOguAZmcfZA2JVkyBlz+of3wVLg1Qnq551cZrfC8qbKrEPZO+TxWcoCVhd 8a97GXfLp8+qThsNqRlTOX6fwmfPbKYtubrYVwlYmwHPID2UsLAm3Hkwk8C1Vut0hlfX +w==
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2057.outbound.protection.outlook.com [104.47.46.57]) by mx0a-00273201.pphosted.com with ESMTP id 2pt8568wyd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 04 Jan 2019 19:05:39 -0800
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4266.namprd05.prod.outlook.com (20.176.78.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.3; Sat, 5 Jan 2019 03:05:36 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::c9e6:54c9:90c8:211e]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::c9e6:54c9:90c8:211e%2]) with mapi id 15.20.1516.000; Sat, 5 Jan 2019 03:05:36 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Thread-Index: AQHUi5qky69pAtgeuk6GIUpsNSYi7qVz1VIAgCLBFICAB70FgA==
Date: Sat, 5 Jan 2019 03:05:35 +0000
Message-ID: <5DCD6C74-7918-45AB-BEA7-2C1A020B4411@juniper.net>
References: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com> <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net> <20181230003002.GC57547@kduck.kaduk.org>
In-Reply-To: <20181230003002.GC57547@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.5.181209
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4266; 6:5xfx53LjcpxXr9zaIqGSjORnFbTOVgOcqo8Jd+3Uo6+3bRFWTvsnt9e3jvDOhhxauBsuzvh6Fz62Fv7qIy7kVnUqZ9xh50QEtp2bqD2WjUMNjRCQvlHqMD1VpI4N+ZYD0vssWhUxQ4REZwdJdPGLb3HC8glhQRSEsWRPtqez0Y76f7mn/CBSTOqxehc3H5sptKLrE8hqavsv4SqjrJEO0ErBdR9NPPlhzwyKnpnnb+M+5aVvIknSeM02O3UA6tNpZBK1pc5O+Wj3XzqRp3Ey6AtZJu4x7+5Yv2QuwNDXRKFVtTSPJb2yDDVqtJ7dVzNyWxrGDpPIbTvMN0NAIHSVuA4tr+bwPsT4cWrAWF3Go145j2w5kNWw7++5a3A4PJ8BNNYwe9d0Y3LY97fue50OCmA47+bAjyo4xvfv1/3uHa2/cE20sKUNsObPnC25Qgmqo4va7F05nlhMdFBmTo9K0g==; 5:LxV7Hbgtr1nn1pig5DvrtgV8EbeB5gjLm8evE3yrlqFP0zrSt1eH6y8PleMnFRF9pskLXRU2Mc4VCBfbJxQWhNMAhsrpu49b82DY0oyAZZ57AHMHlVr+kyPVz4Q0RclUoedsIoy+0omie7uLeBX27hPdvjnggl1+RJa5WJQ/NexAcX1EIt59VunejRPFYnP4qT5DgyYdC3pyQFTjUzG8/Q==; 7:7hA3JavbDCi4JYfo9B+XhMtCD5tCsYYseP1RvZL82Erl0VyRuq1VpWhiClOHg/Vs4Fl9gYofxX3UBBKJs0czr8eHeNYQmpOZlHdjWuvr/Ngq0N8ehdhEml/1OQF1GXxSL5Au/ee0Lmv0wVQlxkb4cQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2021489b-1da0-4c4a-98bc-08d672baaa22
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4266;
x-ms-traffictypediagnostic: DM6PR05MB4266:
x-microsoft-antispam-prvs: <DM6PR05MB42662A8827A59091AA51286AA58F0@DM6PR05MB4266.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93001095)(3231475)(944501520)(4982022)(52105112)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4266; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4266;
x-forefront-prvs: 09086FB5C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39860400002)(346002)(136003)(51444003)(40224003)(189003)(199004)(51914003)(53234004)(6246003)(256004)(6486002)(53936002)(97736004)(966005)(2171002)(14444005)(229853002)(8676002)(25786009)(81156014)(81166006)(76176011)(6506007)(102836004)(36756003)(26005)(6346003)(4326008)(14454004)(186003)(575784001)(86362001)(478600001)(58126008)(4744004)(106356001)(82746002)(68736007)(345774005)(83716004)(54906003)(3846002)(6116002)(2616005)(476003)(7736002)(316002)(6916009)(2906002)(53946003)(6512007)(8936002)(6306002)(5660300001)(11346002)(66066001)(446003)(33656002)(561944003)(105586002)(486006)(99286004)(305945005)(71190400001)(71200400001)(6436002)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4266; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: f5f3XO33F+BUv6+dgchJgF5lrYdRwdt1+fu+bByoSKpESjto1IOlnQaNVWcUoTxN3jwimyWzirJobpZ/qmBbezpAD9xC/TfIzEFjj0anxh7mbXwl0TZBxrgTW0z2TXODQBGIQBr+ixtHWRNxi55EIM8IJuJIHmzEEwu6za9DYNQUxQFnnaduxq5zceG/TIiJl5NCy/5vC3Hu129RVo44oNcwEYjLShUaA+Cg1qkaVx3YkVn6FtV7WPrUjE41iAbTKJzR5ATFntiil4uPwlddDtnuGLaa9LTBiY/73jxRAKLH3lqQlicIIsZH4MwcQYRA
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <432D647C8C634745AD196A0C312FAB8C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 2021489b-1da0-4c4a-98bc-08d672baaa22
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2019 03:05:36.2420 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4266
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-05_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901050023
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Y8bxb_1SX1_Y105vdF_DF3Qmads>
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: Sat, 05 Jan 2019 03:05:46 -0000

Hi Benjamin,

Below are several links to individual GitHub commits, but here's the link
to the complete/rendered draft:

	https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27

Cheers,
Kent


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

Excellent - this item is closed.



>> > (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.)

Please let me know if this update addresses the concern:
https://github.com/netconf-wg/zero-touch/commit/a5086b299f60c00afcaddc0ddf0a0e9d3431c04e





>> > (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]

[Bringing back into this thread]

I emailed the RFC 8366 authors (CC you) regarding your concern with the
minimum-allowed nonce length.

As for this draft, I feel that the easiest solution is to change the YANG
as follows:

       leaf nonce {
         type binary {
-          length "8..32";
+          length "16..32";
         }

It is within the range allowed by RFC 8366 (i.e., no compatibility violation)
while eliminated the low-end that you objected to.  I can't imagine there
being an issue in asking a low-end device (even a measly IoT thing) to generate
an extra 8 bytes of random data.

I've made this change in my local copy.



>> > (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.

I think you mean this commit by my co-author Ian to address a comment from Suresh: https://github.com/netconf-wg/zero-touch/commit/1c846ca3bc6ce8ffe1813a0c864dc3aebaf3af65.

In either case, we believe the issue is resolved in the current (posted) text.
Here is the direct link: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-26#section-8.

Can this DISCUSS item be closed now?


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

Great - this item is closed.


 
>> > 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 have added a new Security Considerations section to highlight this reuse: https://github.com/netconf-wg/zero-touch/commit/62076e8421fd286a74519b60e8346dbf78d3c4f2




>> > 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
> certificate; 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.

As you say, authentication is mentioned in several places already 
and, if I understand you correctly, this text is sufficient.

While the word "authorization" does not appear in this document, 
Section 9.13 discusses "access", which relates to statements in 
RFC 8040, such as:

   The RESTCONF server MUST authenticate client access to any protected
   resource.

   The server MUST NOT allow any RESTCONF operation for any resources
   that the client is not authorized to access.

To provide a more complete picture, the bootstrap server exposes just
two RPCs.  Each RPC *requires* an authenticated client-credential to
function.  That is, "get-bootstrapping-data" can only return the 
bootstrapping data for the authenticated client credential; there is
no other parameter passed for the server to determine which data to 
return. Likewise, "report-progress" can only report progress for the
authenticated client credential; there is no other parameter passed
for the server to determine for which client is reporting the data.

This COMMENT began by asking if we might want references for TLS 
and/or HTTP client authentication, and now maybe authorization.
Given the above discussion, what is your recommendation?


>> > (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.  

Okay, this item seems to be closed then.



>> > 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.)

I added a slightly reduced version of the above text (taking out clause "ii"):
https://github.com/netconf-wg/zero-touch/commit/388d0355b3c7c6ce4aa48028a4ef89dc64147304.

Still good?


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

Okay, let's close this one with no update.



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


Okay, I did the following:

  When referring to the draft/solution:
    Zero Touch --> SZTP

  When referring to the bootstrapping artifact:
    zero touch information --> conveyed information
    zerotouch-information  --> conveyed-information

  For the CMS content types:
    id-ct-zerotouchInformationXML  --> id-ct-sztpConveyedInfoXML
    id-ct-zerotouchInformationJSON --> id-ct-sztpConveyedInfoJSON

  For the YANG modules:
    ietf-zerotouch-information.yang      --> ietf-sztp-conveyed-info.yang
    ietf-zerotouch-bootstrap-server.yang --> ietf-sztp-bootstrap-server.yang

  For the DNS/service name:
    _zerotouch --> _sztp

A big change, though I scripted most of it. Here's the diff:
https://github.com/netconf-wg/zero-touch/commit/394b863d1850019fd451554a9f86c3c10d280d08





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

Correct, Section 4.2 was updated (posted in -26) per Alexey's DISCUSS.
Per your original comment (and his, and Adam's), Section 10.6 now
requests IANA to register the service name "sztp" (was "zerotouch"). 

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

I've just now read draft-ietf-dnsop-attrleaf.  I see the applicability,
but I don't understand your proposal.  Looking at DataTracker, I see
that it is already in RFC Ed Queue, so I think you're suggesting me
treat it as a fait accompli, and add an IANA Consideration section
to register "_sztp", yes?  Assuming that is the case, then what should
be done with the service name registration in Section 10.6, added per
comments from Alexey and Adam?



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

Sounds good, thanks.




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

Excellent (closed)



>> >   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 :)

Edit made in -27.




>> >   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 all good.)

Okay, item closed with no update made.



 
>> > 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 in -26.
 
 
 
>> >   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.

Okay, I added a slightly modified version of the above to -27.


 

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

Okay, if we step back from the stream-parsing angle, and instead just focus
on the TLS truncation concern, my first thought is that said error will be
detected in (a) and (b) will not be entered.  In case (b) is entered, then
it seems that (b) would detect a malformed response from the server, as it
would normally need to do.

 
>> >      *  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?)

Edit made to -27, including the missing "of"s.





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

Okay, let's close this with no update.  That said, you may be pleased (or
irked) to see that the nonce min-length change forced one example to have
to change to "<nonce>extralongbase64encodedvalue=</nonce>" in order to pass
build-time validation tests ;)




 
>> > Section 6.3
>> >
>> > The YANG module boilerplate is still on the RFC 2119 version of BCP 14
>> > (not RFC 8174).
>> 
>> Fixed in -26. 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.
 
Note, a separate WG comment prompted an additional update here.
Now "[RFC2119][RFC8174]" is "(RFC 2119, RFC 8174)", since YANG
modules aren't themselves drafts with a references secton and
such.





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

Is it okay for me to back out of this one?  I had thought previously
that Russ would provide the ASN.1, but he said he didn't have time and,
well, I'd rather not venture into this if it can be avoided...




>> > Section 7.3
>> >
>> > The YANG module boilerplate is still on the RFC 2119 version of
>> > BCP 14 (not RFC 8174).
>> 
>> Yep, fixed in -26 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.

Last sentence removed (and spelling mistake fixed) in -27.





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

Change made (along with fixing "the the") in -27.




>> > 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 :)

Okay, let's close this with no update made.




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

Okay, and for posterity sake, the change was made in -26.




>> > 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.)

Change made in -27.

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

Okay, and for posterity sake, this update was in -26.




>> > 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 :)

Ex excellent and, again, for posterity sake, this update was in -26.


 
>> > 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"?

Okay, slightly modified text to your 2nd suggestion in -27.



 
>> > Section 9.12
>> >
>> > nit: the last word is "revoked".
>> 
>> Fixed in -26.

 
 

>> > 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 in -26.
 
 
>> >                                                         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.

Excellent, and this update was in -26.
 
 
 
>> > 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

Excellent and, again, this update was in -26.




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

Also was in -26.




Thanks again!
Kent