Re: [Gen-art] review of draft-ietf-opsawg-sdi-02.txt

[Warren Kumari <[e-mail]>]

Wow, apologies, I had completely missed this email -- I have a complex
set of filtering rules to allow me to focus on drafts on the upcoming
telechats, and this fell into the cracks.

On Tue, Feb 18, 2020 at 10:57 AM Francis Dupont
<[e-mail]> wrote:
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-opsawg-sdi-02.txt
> Reviewer: Francis Dupont
> Review Date: 20200212
> IETF LC End Date: 20200218
> IESG Telechat date: unknown
>
> Summary: Almost Ready
>
> Major issues: None
>
> Minor issues: crypto use details are missing. IMHO it is a problem of
> presentation, I propose:
>  - make only requirements in the first/normative part
>  - put all details in the appendix/demo part

Thank you.

I have attempted to do this - where I have crypto discussion I am
clarifying that this is just illustrative, and that the vendor should
figure out what is best for their environment. I also suggest vendors
may want to consider draft-gutmann-scep.

>
> Nits/editorial comments:
>   - ToC page 2 and 8 page 11: Acknowledgements -> Acknowledgments

Thank you, done.

>
>   - 2 page 4: there are two kinds of certificates so I suggest at the
>    first occurrence to put "public key certificate".

Done. Thank you.

>
>   - 2 page 5, 2.2 page 5, 4.2 page 6, 5.3 page 10, 7 page 11: e.g -> e.g.,

Done (x8!)
Thank you.


>
>   - 3.1 page 5: as an example of something which could be specified but
>    IMHO should not be: the certificate has (extended) key usages and
>    other policy parameters.

I added:  :The vendor's Certificate Publication
Server should only accept certificates from the manufacturing facility,
and which match vendor defined policies (for example, extended key usage,
extensions, etc.)"

Does this address your concern? I suspect that this section (and
others :-)) will get a fair but of discussion / feedback during IETF
LC, and SecDir / IESG review :-)

>
>   - 4.2 page 6: in "The operator will then encrypt the
>    initial configuration to the key in the certifcate"
>     * the "to" seems a bit strange to me (I expected "with" but I am
>       not a native English speaker)
>     * public key crypto does not provide a way to directly encrypt
>       a large amount of data. IMHO it is not a real problem: just
>       require the key is used to protect the initial configuration
>     * it will be fine to have a bit more than confidentiality, for
>       instance to protect integrity or at least the data length.
>     Last both points are handled by SMIME so again it is only a
>     presentation problem.

Thank you -- the example uses SMIME specifically for this reason. I
was trying to word it in a way that was neither too prescriptive, nor
too convoluted. How is:
"The operator will then encrypt the initial
configuration (for example, using SMIME) using the key in the certificate,
and place it on their TFTP server. "

>
>   - 4.3 page 7: Add that DHCP option 66 is TFTP server name and
>     option 150 is TFTP server address.

Oooh, thank you. Done.

>
>   - 5.1 page 10: I've checked (googled it) the TPM abbrev and it seems
>     the common usage in the context is the expected one (BTW it is
>     not in the RFC editor abbrev table).

Thank you - I expanded it.

>
>   - B.1.1 page 13: IMHO it is a good diea to give the OpenSSL command
>     line (OpenSSL man pages are more than cryptic :-).

Thank you - OpenSSL CLI processing is indeed, um, cryptic. I somewhat
think that this is by design - if someone accidentally publishes their
key, it doesn't actually matter, because no-one will figure out how to
invoke OpenSSL to *do* anything with it :-P

>
>   - B.2.2 page 14: I support the choice of S/MIME: it does the job
>     (including length check) and it is commonly available.
>     Of course there should be better ways but it is clearly far
>     better than a home made solution. BTW as it is encoded ASN.1 it
>     is trivial to recognize (i.e., no ambiguity with ASCII text).

Thank you!

>
>  - B.3 page 15: then then -> then

Oooh, good catch, fixed, thank you.
W


> Regards
>
> [e-mail]
>
> PS: I removed spelling errors which were fixed in version 03.



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf