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

[David Noveck <[e-mail]>]

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

>
>
> > On Apr 4, 2020, at 9:40 AM, David Noveck <[e-mail]> wrote:
> >
> > 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.
>
> 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
>
> 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.