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

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 14 Jul 2021 16:16:00 -0700

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.

---

From: <[email-masked]>
Date: Thu, 15 Jul 2021 05:13:14 +0000

Hi John, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

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

---

From: John Scudder <[email-masked]>
Date: Thu, 15 Jul 2021 16:06:55 +0000

Hi Med,

A couple more comments inline below. 

> On Jul 15, 2021, at 1:13 AM, [email-masked] wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
>> Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-__;!!NEt6yMaO-gk!Sh1wKLda1DQGznlanX_xiLmZjTH9iIAvF9LrQ5s_AWVJt39MDpVfCQKyWFOTMA$
>> criteria.html
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/__;!!NEt6yMaO-gk!Sh1wKLda1DQGznlanX_xiLmZjTH9iIAvF9LrQ5s_AWVJt39MDpVfCQI4fak2Xw$
>> 
>> 
>> 

I suggest using the hyphen as in the earlier comment: “as input four octet-strings”. This makes it unambiguous that “four” modifies “octet strings” and not just “octet”, which is still slightly ambiguous in the non-hyphenated version. Possibly the RFC Editor will have comments too, of course. If you distinctly prefer the non-hyphenated version, it’s not a big deal though.

…

> [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 e…

OK. In that case I think it would be beneficial to choose some other rewrite, to make it unambiguous that you mean something closer to “shall” and less like “will”. The problem is that “should” could mean either. For example,

OLD:
   No device other than the NSH-aware SFs in the SFC-enabled domain
   should be able to update the integrity protected NSH data.
   Similarly, no device other than the NSH-aware SFs and SFC proxies in
   the SFC-enabled domain should be able to decrypt and update the
   Context Headers carrying privacy-sensitive metadata.  In other words,
   if the NSH-aware SFs and SFC proxies in the SFC-enabled domain are
   considered fully trusted to act on the NSH data, only these elements
   can have access to privacy-sensitive NSH metadata and the keying
   material used to integrity protect NSH data and encrypt Context
   Headers.

NEW:
   It is expected that devices in the SFC-enabled domain will be configured
   such that no device other than the NSH-aware SFs in the domain
   will be able to update the integrity protected NSH data, and also
   such that no device other than the NSH-aware SFs and SFC proxies in
   the SFC-enabled domain will be able to decrypt and update the
   Context Headers carrying privacy-sensitive metadata.  In other words,
   if the NSH-aware SFs and SFC proxies in the SFC-enabled domain are
   considered fully trusted to act on the NSH data, only these elements
   can have access to privacy-sensitive NSH metadata and the keying
   material used to integrity protect NSH data and encrypt Context
   Headers.

I haven’t put a lot of thought into this proposal so consider it an example of what I’m talking about rather than a well-crafted replacement (although feel free to use it if you like). (If following this model, maybe after “it is expected” there would be one or more xrefs to the places where these requirements are stated normatively.)

Thanks,

—John

---

From: <[email-masked]>
Date: Fri, 16 Jul 2021 12:01:04 +0000

Hi John,

Please see inline.

Cheers,
Med

> De : John Scudder [mailto:[email-masked]]
> Envoyé : jeudi 15 juillet 2021 18:07
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : The IESG <[email-masked]>; [email-masked]; draft-ietf-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-
[...]
> >> -----------------------------------------------------------------
> ---
> >> --
> >> COMMENT:
> >> -----------------------------------------------------------------
> ---
> >> --
> >>
> >> 1. Section 4.2
> >>
> 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.”)
> >>
> >
> I suggest using the hyphen as in the earlier comment: “as input four
> octet-strings”. This makes it unambiguous that “four” modifies
> “octet strings” and not just “octet”, which is still slightly
> ambiguous in the non-hyphenated version. Possibly the RFC Editor
> will have comments too, of course. If you distinctly prefer the non-
> hyphenated version, it’s not a big deal though.
> 
> …

[Med] Noted your preference, but I'm afraid that we will touch that text to address one of Ben's DISCUSS point. 

> 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.
> 
> OK. In that case I think it would be beneficial to choose some other
> rewrite, to make it unambiguous that you mean something closer to
> “shall” and less like “will”. The problem is that “should” could
> mean either. For example,
> 
> OLD:
>    Context Headers carrying privacy-sensitive metadata.  
> 

[Med] Thanks. Went with the following: 

   It is expected that specific devices in the SFC-enabled domain will
   be configured such that no device other than the classifiers (when
   reclassification is enabled), NSH-aware SFs, and SFC proxies will be
   able to update the integrity protected NSH data (Section 7.1), and
   also such that no device other than the NSH-aware SFs and SFC proxies
   will be able to decrypt and update the Context Headers carrying
   sensitive metadata (Section 7.1).

A full diff can be tracked at: https://tinyurl.com/nsh-integrity-latest