Re: [nfsv4] testing of RPC over TLS

[grarpamp <[e-mail]>]

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.