[sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-sfc-nsh-integrity-06: No Objection

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 DISCUSS and COMMENT positions.


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



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

1. Section 4.2

   The authenticated encryption process takes as input four-octet
   strings: a secret key (K), a plaintext (P), Additional Authenticated
   Data (A) (which contains the data to be authenticated, but not
   encrypted), and an Initialization Vector (IV).  The ciphertext value
   (E) and the Authentication Tag value (T) are provided as outputs.

As written, this means that each of these quantities is a 32 bit string, even P
and A. I think you don’t mean that. If you mean each quantity is a string of
octets, then move the hyphen: “takes as input four octet-strings“. (In the
unlikely event you really do mean each quantity is a string of four octets,
then “… takes as input four strings, each of four octets.”)

2. Section 9

Regarding your use of the term “man-in-the-middle attacker”, you might want to
take into consideration that this language may be seen as exclusionary by some
readers, see also
https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/. I’ve
seen “on-path attacker“ used as a replacement in some cases, but I understand
there may be nuances that make this inappropriate for some uses; it also
appears you might just be able to use “attacker” in your case. The RFC Editor
may have further guidance.

3. Section 9.1

You use “should“ in several places. As written, it isn’t clear if you’re
indicating expectation, or requirement. After reading the whole section, I
think you’re indicating requirement. This seems like a good place for use of
the RFC 2119 style SHOULD keyword.