Re: [nfsv4] testing of RPC over TLS

[David Noveck <[e-mail]>]

There is no way we can make the sort of changes in the existing RFC
candidate that you propose, at this point.   The document has already
successfully been through WG last call, IETF last call and IESG
consideration and has a good chance of resulting in an RFC within 2021   If
we were to decide that we wanted to significantly change it, we would be
delaying publication for at least a year.   As a result, we would be living
even longer with the current approach to NFSv4 security including the use
of AUTH_SYS without any client host authentication whatever :-(. Sigh!

The benefits that you anticipate from your proposed changes would have to
be balanced against the negative consequences of a delay in rpc-tls as
currently defined.    That is not worth it.   The proper time to raise and
address these sorts of issues was during WGLC, which ran from 11/24/2019 to
12/23/2019.  In any case, the document approved by the working group did
not take the view that you do regarding these issues.

It is possible for the working group to change its mind and start work on a
revised RFC.   You can propose that to the working group.   Another
possibility is to address these issues in an nfsv4-specific context (rather
than in a general rpc context) as part of the anticipated RFC deriving from
an eventual draft-ietf-nfsv4-security.    I'd appreciate it if you
provided material regarding these (and other important) security issues
that would fit in draft-dnoveck-nfsv4-security-needs.   I think it would be
best if we incorporated all these before submitting
draft-ietf-nfsv4-security-needs.

On Fri, Nov 27, 2020 at 6:02 AM grarpamp <[e-mail]> wrote:

> On 11/27/20, Benjamin Kaduk <[e-mail]> wrote:
> >> > https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt
> >>
> >> How do users and administrators pin down the
> >> public key fingerprint of the NFS server's TLS certificate
> >> so that the hash is checked and thus a MITM
> >> attack is prevented?
>
>
> > only vocal proponent of this
>
> Often NFS users and admins...
> Are in and from nice private LAN environments, not public services.
> Aren't necessarily oriented to other nasty threat models.
> Come from legacy schools of thought that still incorrectly
> believe "CA" validation is all that's needed to neuter MITM.
>
> That's of course not universal, but "only" is relative,
> and in no way invalidates the considerations for pinning.
>
> If something speaks TLS, it needs to have pubkey
> pinning options.
>
>
>
> If RFC compliant implementations must do some
> certain things re TLS, then RFC can also say that...
> "5.2.3 Fingerprint pinning
> Implementations must offer options to configure
> pinning of the TLS certificate pubkey fingerprint hash".
>
> Some simple sentence like that is all that's needed.
> Then all the implementations, such as FreeBSD's,
> will have the option, users can read their manuals
> and use it as desired or not.
>
> If not put in the RFC, then some better implementions will
> have them, other lesser ones won't, the space for nfsv4
> interop will thus be fragmented, users who want to use
> pinning will be constrained to certain OS's, comparisons
> made, etc.
>
> FreeBSD has a good degree of security consciousness,
> so it would be great and not surprising for them to offer
> pubkey pinning for their users and admins from the start.
>
>
>
> Sections 4 and 5 already require lots of things re TLS... so there
> is no reason it cannot also require the *options* to configure
> pubkey and CA pinning... further info on those can be included
> in references and appendix (while indeed at same time progressing
> more formal material in IETF or elsewhere).
>
> 5.2.3 Fingerprint Pinning
> [opts required]
> 5.2.3.1 Pubkey Hash
> [defn refs]
> 5.2.3.2 Certificate Hash
> [defn refs]
>
>
> "
> 5.2. TLS Peer Authentication
>
>    TLS can perform peer authentication using any of the following
>    mechanisms.
>
> 5.2.1. X.509 Certificates Using PKIX Trust
>
>    RPC-over-
>    TLS implementations are REQUIRED to support the PKIX mechanism
>    described in [RFC5280].
> "
>
>
>
> > "PKI vs. Pinning" section of
> > https://datatracker.ietf.org/doc/minutes-108-saag/
>
> The above sentence also rightly avoids such TLS debates...
> - "scale"
> - "decisions about which rogue / forced / compromised CA's to 'trust'"
> - what "AV" "Google" companies think
> - namespaces, grand pie sky schemes
> - whether or not anyone thinks users need pinning or not
> - etc
>
>
> Pinning to the CA is not the sole and universal option for all users.
> For one, CA / Let's Encrypt sigs expire, such expiry is meaningless,
> the rotation causes excess "scale" maintenance under cert level pins,
> CA $igs often don't mean anything to real security contexts... and it
> has already been noted that any privkey compromise will result in the
> pubkey hash changing anyway, so CA is either moot or secondary
> to that pubkey fundamental. Pinning the pubkey "end entity cert"
> is the underlying simple method to avoid any concerning about CA.
>
>
> Users TLS environments, needs, models, validations...
> are different from debaters... instead stick to how
> to get the option into all implementations.
>
> But to not even mention pinning in RFC, to have removed it,
> not even having as 5.2.2's "optional option", or more fully
> detailed in Section 7 security considerations... seems potentially
> a bit irresponsible, particularly now that other TLS client-server
> applications are making some more mention and implement of it.
>
>
> https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls
>
> "
>    In 2014 the IETF published a document entitled "Pervasive Monitoring
>    Is an Attack" [RFC7258], which recognized that unauthorized
>    observation of network traffic had become widespread and was a
>    subversive threat to all who make use of the Internet at large.  It
>    strongly recommended that newly defined Internet protocols should
>    make a genuine effort to mitigate monitoring attacks.
> "
> "
>    A classic form of attack on network protocols that initiate an
>    association in plain-text to discover support for TLS is a man-in-
>    the-middle
> "
>
>
> > watch the recording and read the associated email thread
>
> https://mailarchive.ietf.org/
>
> IETF has configured CloudFlare (which btw is in fact a MITM,
> for which too few have contemplated that problem) to block
> users of VPN and other overlay services who would otherwise
> be quite happy to watch or read such things at that URL.
>
> Didn't see a video link in the minutes link.
>
>
> Best regards.
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>