Subject: [nfsv4] Sending a stronger message in rpc-tls

From: David Noveck <[email-masked]>
Date: Sat, 4 Apr 2020 09:40:01 -0400

One possibility to consider is replacing the penultimate paragraph of the
Introduction by the following two paragraphs.

The current document assumes policies in line with [RFC7435]
in order to enable RPC-on-TLS to be deployed opportunistically in
environments that contain RPC implementations that do not support
TLS. Specifications for RPC-based upper-layer protocols will often
choose to require stricter policies in order to guarantee that encryption
or host authentication is in use on every connection.

Imposition of such stricter policies is of particular importance with
regard to
protocols for which the within-protocol security infrastrucure is weak,
allowing common deployments without encryption of request and response
data or providing attackers the opportunity to easily obtain server
execution
of substantively unauthenticated requests, with authentication presumptively

provided by the clients (e.g. using AUTH_SYS), which themselves have not
been authenticated.

---

From: Chuck Lever <[email-masked]>
Date: Sun, 5 Apr 2020 10:38:15 -0400

> On Apr 4, 2020, at 9:40 AM, David Noveck <[email-masked]> wrote:
> 
> One possibility to consider is replacing the penultimate paragraph of the Introduction by the following two paragraphs.
> 
> Imposition of such stricter policies is of particular importance with regard to 
> data or providing attackers the opportunity to easily obtain server execution 

Forgive me, Dave. You removed the context, so I'm not certain which of
Magnus' comments you're responding to. Can you clarify?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sun, 5 Apr 2020 12:54:00 -0400

On Sun, Apr 5, 2020 at 10:38 AM Chuck Lever <[email-masked]> wrote:

> > One possibility to consider is replacing the penultimate paragraph of
> the Introduction by the following two paragraphs.
> >
> Hope so.

I was referring back to the following text from one of Magnus's
followup message sent Apr 1.

 > > The mechanism is clearly opportunistic in its establishment, however
the
> > goal here needs to be to get support in as many places is as possible.
>
> Yes.
>
> > Thus, sending a clearer signal that NFS 4.x servers and client are
expected
> > to support this should be sent.
>
> I think we can figure out how to send a clearer signal.

I guess I mixed up "stronger" and "clearer" but I think my proposed text
does send a clearer signal.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 Apr 2020 17:12:29 -0400

> On Apr 5, 2020, at 12:54 PM, David Noveck <[email-masked]> wrote:
> 
> On Sun, Apr 5, 2020 at 10:38 AM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Apr 4, 2020, at 9:40 AM, David Noveck <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> I was referring back to the following text from one of Magnus's followup message sent Apr 1.
> 
>  > > The mechanism is clearly opportunistic in its establishment, however the
> > > Thus, sending a clearer signal that NFS 4.x servers and client are expected
> I guess I mixed up "stronger" and "clearer" but I think my proposed text does send a clearer signal.

As part of addressing the recent AD review of rpc-tls, I've merged your proposed text into the
Introduction, and updated Section 7.1 to make a stronger statement about the enforcement of
the use of TLS authentication and encryption.

A diff of a working copy of this document with the -06 revision highlights these changes:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-nfsv4-rpc-tls.txt&url2=https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.txt

As mentioned in another thread, there's more work pending on this document, but please do have
a look and send your comments. Thank you!

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Apr 2020 20:42:27 +0000

> a look and send your comments. Thank you!

Hi,

I think this is an improvement when it comes to strengthening the message. Lets
proceed with what we have. 

I also saw in the diff good changes to address, IANA section, discussion of
privacy leaks and the ALPN tie in. 
 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------