Secure Device Install
RFC 8886

Note: This ballot was opened for revision 09 and is now closed.

Robert Wilton Yes

Alvaro Retana No Objection

Comment (2020-05-19 for -10)
No email
send info
I support Roman's DISCUSS.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-06-19 for -12)
Thanks for the updates in the -12 (and -11?  My notes claim I reviewed the -10, though
the datatracker history says it was the -11; perhaps there was some skew between when
I opened the doc and balloted).  They get most of the way to where I want us to be, so
I'm switching to No Objection.  That said, the Abstract and Introduction still feel like
they're slightly overstating the confidentiality protection attainable with this mechanism:

The Abstract currently says "to provide confidentiality to initial configuration
during bootstrapping", but we may need to hedge that a bit more, e.g., that this is
partial or limited confidentiality.  Similarly, Section 1 currently says "while maintaining
confidentiality of the initial configuration", and would get similar treatment.

Finally, I see that you took my suggestion of using "directory service" instead of
"Certificate Publication Server".  It may be worth a reference for this concept -- e.g., Section 2.1 of 
RFC 5280 references both [X.500] and RFC 4510 as potential ways to provide 
directory service for obtaining certificates.

Erik Kline No Objection

Comment (2020-05-20 for -11)
[[ comments ]]

* Perhaps a suggestion that vendors might want to have a factory-installed
  option for interested customers that /only/ an encrypted config can be tried
  and no attempt to use a plaintext config will be made.

* Security considerations paragraph about control of the configuration server
  should include a mention that the key is not required for interference if
  the booting device will happily fall back to loading a cleartext config.

* Though less common than DHCPv4, consider acknowledging the broader (open)
  issue of file/TFTP server service discovery (DHCPv6, RAs plus resolution of
  a well-known hostname, DNSSD, ...).

[[ nits ]]

[ section 4.2 ]
* "Publish TFTP Server" --> "Publish to TFTP Server", perhaps

Martin Duke No Objection

Comment (2020-05-20 for -11)
No email
send info
I support Roman’s discuss.

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2020-05-16 for -10)
Bigger points first:

The shepherd writeup contains this remark, which made me squint a bit: "More security review was asked for by the WG at various [times], and it is not clear that this input will be taken into account."  Why's that?

This Informational document cites BCP 14, and then has a solitary SHOULD in Section 4.2.  One could easily change "SHOULD fetch" to "fetches" and do away with all of that.

There are several places where the prose uses two words to mean roughly the same thing (e.g., "store / cache").  I found this awkward each time I hit it.  Please, in each case, pick one.  Worst case, replace the slash with "or", but you'll probably find that redundant anyway.

There are several places where a list or example is introduced with a hyphen (e.g., "There are two options when implementing this - a vendor could...").  Instead, it should be a new sentence, or at least a colon followed by a clause or maybe a bulleted list.

And now, a lot of editorial suggestions:

Section 1:
* "... or using an auto install techniques which fetch ..." -- s/techniques/technique/, or remove "an"
* "... or something similar, is an unacceptable ..." -- remove the comma
* "... vendor to pre-configure the devices before shipping it ..." -- change either "devices" to "device", or "it" or "them"
* "... configuration, etc; but these ..." -- change to "... configuration, etc.  However, these ..."
* "... managing installed / deployed devices ..." -- suggest just picking one

Section 2:
* "... newly installed / unconfigured ..." -- change to "... newly installed, unconfigured ..."
* "... obtain an IP address and address of a config server ..." change to "... obtain an IP address for itself and discover the address of a configuration server ..."
* "This document describes a concept ..." -- this paragraph feels like it belongs in Section 1

Section 2.1:
* "... Point of Presence (POP) / datacenter." -- maybe just replace all of this with "facility"?
* "... device configuration, fetches the certificate ..." -- s/,/ and/
* "... encrypted config ..." -- please use either "configuration" (preferred) or "config", but not both
* "... installed in Operator_A' ..." -- missing an "s" (two instances in the third paragraph)
* "... (note that all this ..." -- s/all this/all of this/ (and actually, this should be its own sentence)

   The device attempts to load the
   config file - if the config file is unparsable, (new functionality)
   the device tries to use its private key to decrypt the file, and,
   assuming it validates, installs the new configuration.
   The device attempts to load the configuration file.  As an added
   step, if the configuration file cannot be parsed, the device tries
   to use its private key to decrypt the file and, assuming it validates,
   proceeds to install the new, decrypted, configuration.

* "(See Security Considerations)" -- section number, please

Section 3:
* This section doesn't appear to me to describe a role other than "vendor".
* "... the vendors roles and ..." -- s/vendors/vendor's/

Section 3.1:
* Please expand "EST" on first use.

Section 3.2:
* "... store / cache ... uptime / reachability ..." -- as above, these really stand out to me as in need of making an editorial choice

Section 4:
* I don't see a role in here either other than "operator".

Section 4.1:
* "(likely serial number)" -- suggest "(e.g., the serial number)"

Section 4.2:
* "publication server, and download ..." -- remove the comma

Section 5.1:
* "chassis / backplane" -- another; see previous remarks
* TPM could use a reference (ISO/IEC 11889?)

Section 5.3:
* "(e.g.: 'load replace <filename> encrypted))" -- unbalanced quoting and parentheses

Section 7:
* "... may wish to bootstrapping devices with ..." -- s/bootstrapping/bootstrap/
* "... minimal / less sensitive ..." -- pick one, or at least use "or"

Appendix B:
* s/csr/CSR/ (and probably expand it)
* "Demo / proof of concept" -- pick one
* "... from the command line, in production ..." -- start a new sentence
* Don't use "I'm".  Maybe change "I'm using S/MIME because ..." to "S/MIME is used here because ..."

Roman Danyliw (was Discuss) No Objection

Comment (2020-06-24)
No email
send info
Thank you for addressing my DISCUSS and COMMENT items.

Éric Vyncke No Objection

Comment (2020-05-19 for -10)
Thank you for the work put into this document. The document is easy to read.

Please also reply to Nancy's IoT directorate review at:
(Thank you Nancy for the review)

I am also trusting my security AD peers for the security aspects.

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,




Should the "IP address" be scoped ? I.e., is it global scope or (IPv4 and IPv6) link-local only ?

-- Sections 1 & 2 --
PLEASE when mentioning DHCP also refer to DHCPv6 RFC 8415 (trusting the authors to fix this before final publication). You may also explore whether IPv6 Router Advertisement / PvD could be an option.

-- Section 1.1 --
This is an informational document, so, I wonder whether a reference to BCP 14 is useful. (see also Murray's comment on section 4.2)

-- Section 4.2 --
Is there a reason to suggest the use of TLS to fetch the certificate? Normally a certificate is public information and is authenticated.

-- Section 5.1 --
Is there a need to store the public key (and the associate cert I guess) in TPM ?

Warren Kumari Recuse

Comment (2020-05-11 for -10)
No email
send info
'm an author...

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-05-20 for -11)
I support Benjamin's DISCUSS.

Section 3.1: I'm not thrilled to see EST and SCEP suggested on equal footing, since my understanding is that the design of EST is preferable to that of SCEP and we are only publishing SCEP because it is in wide use, not because vendors who have a choice should choose it.

(Barry Leiba; former steering group member) No Objection

No Objection (2020-05-19 for -10)
Just a nitty load of nits nitting about:

— Section 1 —

   Internet Exchange Points (IXP) or "carrier neutral

Nit: hyphenate “carrier-neutral”,

   vendor proprietary) protocols to perform initial device installs

Nit: hyphenate “vendor-proprietary” (or just drop “vendor”).

   use DHCP [RFC2131]to get an IP address

Nit: add a space after the citation.

   security related and/or proprietary information

Nit: hyphenate “security-related”.

   (or using an auto-
   install techniques which fetch an unencrypted config file

Nit: remove “an”.

   perform the initial configuration work; this costs, time and money.

Nit: remove the comma.

   configure the devices before shipping it;

Nit: “device” (or “them”).

   optimized for simplicity, both for the implementor and the operator;

Nit: make it “for both” (or repeat “for” before “the operator”).

   is it intended to solve all use-cases

Nit: do not hyphenate “use cases”.

   Solutions such as Secure Zero Touch Provisioning (SZTP)" [RFC8572],

Nit: there’s an unpaired quotation mark.

— Section 2 —

   the devices serial number, MAC address or similar.

Nit: Make it “device’s” (possessive).

   extends this (vendor specific) paradigm

Nit: hyphenate “vendor-specific”.

— Section 2.1 —

   When the device arrives at the POP, it gets installed in Operator_A'

   autoboot state, and begins the DHCP process.  Operator_A' DHCP server

Nit: “Operator_A’s” in both places.

— Section 3.1 —

   Each devices requires a public-private key keypair

Nit: “Each device”
Nit: you don’t need “key keypair”; I suggest “key pair”.

   (for example, extended key usage, extensions, etc.)

Nit: “for example” and “etc.” don’t go together; use one or the other.

— Section 4.3 —

   configurations fails, the device will either abort the auto-install
   process, or will repeat this process until it succeeds.

Nit: “configuration” (singular).
Nit: remove the second “will” (or make it “either will”).

— Section 5.2 —

   completely replace the initial device generated key

Nit: hyphenate “device-generated”.

   operators installed key.

Nit: “operator’s” (possessive).

— Section 5.3 —

   device management, whereby portions (or the entire) configuration

Nit: “portions of”

— Section 7 —

   third-party to copy and paste it over a serial terminal.

Nit: “them”, not “it” (the antecedent is plural).

   An attacker (e.g., a malicious datacenter employee) who has physical
   access to the device before it is connected to the network the
   attacker may be able to extract the device private key

Nit: remove “the attacker”.

   Even when using a secure bootstrapping mechanism, security conscious
   operators may wish to bootstrapping devices with a minimal / less
   sensitive config

Nit: hyphenate “security-conscious”.
Nit: “bootstrap” (no “ing”).
Nit: hyphenate “less-sensitive”.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection (2020-05-21 for -11)
No email
send info
Support Ben and Roman's discusses. Even if the goal is to have a simplified solution with lesser guarantees it appears that the general architecture is so weak that it is easy to circumvent the protection it appears to apply.