Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04

[Tom Talpey <[e-mail]>]

> -----Original Message-----
> From: Chuck Lever <[e-mail]>
> Sent: Friday, December 6, 2019 2:12 PM
> To: David Noveck <[e-mail]>; Black, David
> <[e-mail]>
> Cc: Tom Talpey <[e-mail]>; NFSv4 <[e-mail]>
> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
> 
> 
> 
> > On Dec 6, 2019, at 11:53 AM, David Noveck <[e-mail]>
> wrote:
> >
> > On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey <[e-mail]>
> wrote:
> > > -----Original Message-----
> > > From: nfsv4 <[e-mail]> On Behalf Of Chuck Lever
> > > Sent: Friday, December 6, 2019 10:11 AM
> > > To: David Noveck <[e-mail]>
> > > Cc: NFSv4 <[e-mail]>
> > > Subject: [EXTERNAL] Re: [nfsv4] Review of draft-ietf-nfsv4-rpc-tls04
> 
> >> Essentially, we want to require that the host separates
> >> the encryption of each tenant's traffic.
> >
> > I think the move from "user identiy domain" to "tenant" is helpful here even
> > though you would have to explain what multipe tenants, which, as Tom
> > points out, can alsooccur without virtalization per se, bein involved.
> 
> 
> Fair 'nuf. To me "tenant" and "user identity domain" mean the same thing
> in this context. In Linux, a tenant container is represented by a set of
> namespaces, one of which controls the user identity mapping. So "user
> identity domain" seems natural to me, but maybe not to others.
> 
> RFC 4949 does not have a convenient definition of "tenant."
> 
> RFC 7644 Section 6 comes close.
> 
> David Black, perhaps you might have thoughts based on your work on
> network virtualization overlays ( RFCs 736[45] )?

I'm arguing the opposite - that there's no need to bring in "tenant" or
"virtualization" or adding references to nvo, etc. Unless you have a very
specific vulnerability in mind that this needs to cover.

In other words, keep it simple and at the highest-level abstraction possible.

Tom.

> >> I don't think this is limited to a virtualization environment, or the behavior
> >> of the host partition/process. It's more generally a matter of key
> management,
> >> isn't it?
> >
> > That seems right to me.
> >
> >
> >> The more general statement in that case might be that the key(s) used to
> >> protect the TLS connections MUST be managed in such a way that do not
> >> impact the privacy or integrity of one another. For example, if Coke and
> Pepsi
> >> were both guests of a single host, the keys used for their RPC/TLS mounts
> >> MUST NOT allow Coke to attack Pepsi.
> >
> > Good requirement but I think it needs to be stated in terms of what the
> > implementation is to do, rather than what it needs to prevent.
> 
> I agree that this has become implementation guidance. But I'm still not
> clear on exactly how to state this recommendation/requirement.
> 
> For one thing, the use of compliance keywords might no longer be appropriate.
> 
> 
> --
> Chuck Lever
> 
>