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

Kent Watsen <kwatsen@juniper.net> Sat, 08 December 2018 02:46 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 BAD18131088; Fri, 7 Dec 2018 18:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.16
X-Spam-Level:
X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 S0YGF4h8fU2l; Fri, 7 Dec 2018 18:46:17 -0800 (PST)
Received: from mx0b-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 17BC0131072; Fri, 7 Dec 2018 18:46:17 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wB82jFv2020448; Fri, 7 Dec 2018 18:46:16 -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=56mC0hVP9+oo8w0x0ozTet184RlNEC+7oqe8bEziJ00=; b=mVL1Ze8KVeGJFvForGz9uneOEy8aw7lVtsnMFIR/fDCPm1dsKVI5RVs685le7Aa7uouM LBeRManq3ab4X3rwr/h+iSd/HC9/EUZ+dy33bZp2l8phkCW7cVp5U6RjWTU+vh0Ppa54 +WJ7XBZn9wE6AVsI8o/9xwXlV1d+IiELty6HKeUTqWT2gJpWTUBRlXk5rEb3EoRsYlQ/ At1MEtex8DUzJzi0z9gxBUkrxChsNNiXp1g8Mi+UXf8KCGXY9kYBwO3juUMuIR/inxkh 1zLwKFkFfOn/TPzBRCHRlmXxuuB/UMBCNiOJHPG7WidTngrSARBQnhoNIANXmowAQWNq cg==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2057.outbound.protection.outlook.com [104.47.38.57]) by mx0a-00273201.pphosted.com with ESMTP id 2p81wpg9db-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Dec 2018 18:46:15 -0800
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4124.namprd05.prod.outlook.com (20.176.72.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.8; Sat, 8 Dec 2018 02:46:11 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c%2]) with mapi id 15.20.1425.010; Sat, 8 Dec 2018 02:46:11 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "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: AQHUi5qky69pAtgeuk6GIUpsNSYi7qVz1VIA
Date: Sat, 8 Dec 2018 02:46:11 +0000
Message-ID: <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net>
References: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com>
In-Reply-To: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.4.181110
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4124; 6:CoReXSerTbcwN4aC2S3v2V4lJ8lxOT9axb1szS+iiP2yypsBrPdoHVYxGhn9cslRzljPB91SMcnPa+8VqwK4kh+C5AltGvJsLHdeA2S/UWgKNE3gL11EFE96JjNGTQsyL8EaSh8Vo0842WwfSv6mma4aD+X0A2zrPv6sasHsBGrADxfeE1xQ51c5YQg7HgAbxcd8Aos9peqZFTKVWDbJOpAZ8ILUERmOqntwrPjjNjfjvtWmQpchAVP1ZMkQqe3Dy7cLmoevFGz59KwNzGRhaQbGZUKKaQWYpbawCmdOH1JW03oY+WGweDFSIpxXHJPxgOblTXmfmhFYUjHkKnE2Oak4nclKGeCjeyN7mFMU3jRAZ+/e5GCyvsDW8bUne/nlv8LKGVHXHCsG8EBu2YEvIsVJdjH+i10eYh/LdME9NxULznoLHu1J2GqkQOpSRLny2K09JVcgzgIHTJMozy9qaQ==; 5:0Fne7C/yFvBc7zpfUcP0E6ZcIzg+TjhBFnlz1XzSxQAOsQJ2PCP0DxpD3eptBvjiTSbBoAokFtsx4paOkbcQAReVQF16euRdoMFnIkoS6e4tM8Z/7wYOz5V/Oe2gIhQvcSxkMDniWXwKILOsz+txB49ZiZ14dLXTE/hLFspk4bM=; 7:BPAG4b208qc9SAVOh7ow0cZXgbyct/nNXh7+azgIIxWWPXS8pdXYteHmRKJxx9XsEYQw1V3XTqdTNZ8dl+NKZ6zBsEw0v+wThWhyuv8VOxJcMv3zO+uUljNtIAfXp3rvxsvsDppOI2TSMOpKAC+C6w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b411f0e5-ba82-4443-4810-08d65cb75044
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4124;
x-ms-traffictypediagnostic: DM6PR05MB4124:
x-microsoft-antispam-prvs: <DM6PR05MB41240192083E278976CC31CBA5AB0@DM6PR05MB4124.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231455)(999002)(944501520)(4982022)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4124; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4124;
x-forefront-prvs: 0880FB6EC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(376002)(136003)(346002)(199004)(189003)(40224003)(51444003)(36756003)(14444005)(256004)(8676002)(6486002)(66066001)(966005)(82746002)(486006)(6436002)(102836004)(86362001)(446003)(476003)(2616005)(11346002)(5660300001)(2906002)(478600001)(33656002)(6506007)(81156014)(76176011)(3846002)(6116002)(14454004)(81166006)(229853002)(8936002)(99286004)(7736002)(6246003)(345774005)(53936002)(2171002)(106356001)(58126008)(305945005)(25786009)(53946003)(6306002)(54906003)(105586002)(26005)(68736007)(110136005)(97736004)(71200400001)(186003)(71190400001)(316002)(6512007)(4326008)(4744004)(83716004)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4124; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 2diGnNjIU6HLWVmC9Uc/sqKI0UN8PeaOJ8dAZXZT8OWZSfQ7tGmDXecv9klVY1Xwfchp9e7f8XdxEwZ1/aXOn869NGTgt4CHi1kEjnoionhw5hWtg+FH/lAxuyBiZ6ovajNCVTadyW2JrhantNljsniTuwQ9jrNey6j4g4TV1f+E3YdTbpzFSB+yucp8CudmTauDXQ+69o8l26bciHkXnmqig6Y93OuKrUOCQkpmK7HsAhDYwyo7M5OlXfO9yfoUgp922Gr7g8+5iA6T9HlqkAKAvrL8pt9+iHMMgqYMaEe4m9J/jpzQxOhtWCZV/2hXcB/RJmiIDG1y/sOpPE9DtN80JhmUVzxzfJwpZAe2QeI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <51FF099A913F004899113F4AA259FE74@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b411f0e5-ba82-4443-4810-08d65cb75044
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2018 02:46:11.3675 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4124
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-08_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-1812080023
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/19dsWCAijlk-4TWZPpKaZoeYzF8>
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, 08 Dec 2018 02:46:22 -0000

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

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




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




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




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


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



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



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



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



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



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



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



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

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?



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


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


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




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



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



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



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



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


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



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



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



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



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



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



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



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


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



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




> Section C.3
>
> We could perhaps recommend ecdsa-sha2-* keys instead of ssh-rsa keys.

Replaced "ssh-rsa key" with "SSH public key"




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



Thanks again!
Kent