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

[[e-mail]]

Hi John, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[e-mail]] De la part de John Scudder
> via Datatracker
> Envoyé : jeudi 15 juillet 2021 01:16
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-
> integrity-06: (with COMMENT)
> 
> 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.”)
> 

[Med] Good catch. Changed to "as input four octet strings:"

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

[Med] Agree. Already fixed as part of Lars's review. 

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

[Med] The normative language is not used because these are somehow covered by other normative text in the main document. See for example the statements about providing key materials to authorized entities and so on. 

> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.