[OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-sdi-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 3.2.  If keying material is being distributed as a certificate, do
the expected behaviors of certificate process apply?  For example, how is
expiration handled?

--  If a customer downloads a certificate from the publication server and it is
expired, what should be done?

-- If a certificate is loaded in the TPM of the device, should the client stop
accepting configurations if it expires?

** Section 4.3.  “After retrieving the config file, the device needs to
determine if it is encrypted or not.  If it is not encrypted, the existing
behavior is used.”  What downgrade protection is assumed or recommended here. 
A rogue data center employee could re-target a DHCP response to a server of
choice which provides only unencrypted, tainted configuration.  It would seem
that a device expecting an encrypted configuration should not accepted
unencrypted ones (or at least this should be a policy consideration).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** I struggled a bit to understand where this solution was applicable.  For
example:

Abstract: “This document extends existing auto-install / Zero-Touch
Provisioning mechanisms to make the process more secure.”

Section 1: “this document layers security onto existing auto-install solutions
to provide a secure method to initially configure new devices”.

-- Which “auto-install” and “zero touch provision mechanisms” is this updating?

-- What exact preconditions are necessary to make this “solution” (reference
architecture?) applicable?  Would this still be useful if the “auto-install”
mechanism was encrypted?  What non-DHCP configurations should be considered? 
Does the way the device identifier bind to the configuration matter?  Because
there is little specificity, it is difficult to review the security properties.

** Per the Security Considerations, what new security services does this
overlay provide?

** Section 2.  Per “This document extends this (vendor specific) …”, what is
“vendor specific” about this approach?

** Section 4.2. Per “The operator will then encrypt the initial configuration
(for example, using SMIME [RFC5751]) using the key in the certificate, and
place it on their TFTP server”, is this always a TFTP server, or is this only
an example – I think this is an example?

** Section 4.3.  Per “Give up, go home” in the figure, is there a retry
procedure?  The text above states that “If it cannot decrypt the file, or if
parsing the configurations fails, the device will either abort the auto-install
process, or will repeat this process until it succeeds.”

** Section 7.  Per “An attacker (e.g., a malicious datacenter employee)”, also
a malicious shipping agent.

** Editorial
-- Abstract.  Editorial. I would recommend generalized wording to replace the
phrase ‘smart-hands’-type support.

-- Section 1.  Editorial. “asking the smart-hands to …”, Recommend generalizing
this reference.

-- Section 1. Editorial. “not intended to be an ‘all singing, all dancing’
fully featured system”, Recommend removing this colloquialism.

-- Section 3.1. Typo. s/Each devices requires/Each device requires/

-- Section 3.1.  Typo. s/cryptograthic/cryptographic/

-- Section 4.3. Typo. s/dependant/dependent/

-- Section 4.3. s/retrys/retries/