Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10

[Chuck Lever <[e-mail]>]

> On Feb 24, 2017, at 1:28 PM, Tom Talpey <[e-mail]> wrote:
> 
> [eliding some lines for brevity]
> 
>> -----Original Message-----
>> From: Chuck Lever [mailto:[e-mail]]
>> Sent: Friday, February 24, 2017 1:58 PM
>> To: Vincent Roca <[e-mail]>
>> Cc: IESG <[e-mail]>; [e-mail]; draft-ietf-nfsv4-
>> [e-mail]
>> Subject: Re: Secdir review of draft-ietf-nfsv4-rfc5666bis-10
>> 
>> 
>>> On Feb 24, 2017, at 4:59 AM, Vincent Roca <[e-mail]> wrote:
>>> 
>>> Hello,
>>> 
>>> I have reviewed this document as part of the security directorate’s
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG. These comments were written primarily for the benefit of the
>>> security area directors.  Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>> ... 
>> Hi Vincent-
>> 
>> Thanks for your review.
>> 
>> I believe your questions are mostly rhetorical, so I will respond to those by
>> saying the authors, shepherd, and AD will attempt to address these issues with
>> the next document revision.
>> 
>> There is one remaining comment that IMO needs group discussion, below.
>> 
>> 
>>> ** Privacy or confidentiality? Throughout section 8, authors mention
>> "Privacy" inappropriately IMHO.
>>> Privacy refers to PII (Personally identifiable information) which is different.
>> For instance in section 8.2, when saying:
>>>        "However, integrity and privacy services require significant movement of
>> data on each endpoint host."
>>> the authors really mean confidentiality (this is mentioned just above,
>>> when saying that RPCSEC_GSS implements "per-message confidentiality").
>> There are several mistakes of that kind throughout section 8.
> 
> Regarding "privacy", this term is used in the document because all the NFS RFC's use it in this way.

For example, RFC 7861 "Remote Procedure Call (RPC)
Security Version 3" has this:
 
///  enum rpc_gss_service_t {
///           /* Note: The enumerated value for 0 is reserved. */
///           rpc_gss_svc_none
///           rpc_gss_svc_integrity
///           rpc_gss_svc_privacy
///           rpc_gss_svc_channel_prot = 4
///  };

The term "privacy" as used in rfc5666bis comes from
RPCSEC.


> While I agree with you that there is room for confusion, it would be even wider if we switched terminology here.

Perhaps we should consider replacing "per-message
confidentiality" ?

>> ...
>>> ** Last sentence:
>>> 	"To address attacks on RDMA protocols themselves, RDMA transport
>> implementations should conform
>>> 	to [RFC5042]."
>>> "should" or "SHOULD"?
>> 
>> Lower case "should" is used here because this statement is IMO not an
>> interoperability directive. I hope I correctly understand the intent of your
>> question.
>> 
>> If there is a security requirement that this be changed to the RFC 2119 term,
>> please let us know and that can be done.
> 
> I don't think SHOULD is appropriate here. This statement refers to other protocols, in particular lower layers then this document, and in the case of the relevant IETF RDMA protocols, RFC5042 is already a required conformance. Therefore the statement is informational here, and not an RFC2119 usage.
> 
> Tom.
> 

--
Chuck Lever