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

[John Scudder <[e-mail]>]

Hi Med,

A couple more comments inline below. 

> On Jul 15, 2021, at 1:13 AM, [e-mail] wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-__;!!NEt6yMaO-gk!Sh1wKLda1DQGznlanX_xiLmZjTH9iIAvF9LrQ5s_AWVJt39MDpVfCQKyWFOTMA$
>> criteria.html
>> for more information about DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/__;!!NEt6yMaO-gk!Sh1wKLda1DQGznlanX_xiLmZjTH9iIAvF9LrQ5s_AWVJt39MDpVfCQI4fak2Xw$
>> 
>> 
>> 
>> --------------------------------------------------------------------
>> --
>> 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:"

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.

…

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

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