Subject: [nfsv4] TLS Fingerprint Pinning Needed

From: grarpamp <[email-masked]>
Date: Sun, 29 Mar 2020 17:49:00 -0400

https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls

People appear to be talking about using and
"authenticating / verifying" TLS certs now with at least
perhaps this NFSv4, and certainly with other apps.

If so, it's required critical thing for the admins and users to have
the option to pin the certificate pubkey fingerprints in four ways...

- Ignore the CA chain / expiry / etc, validate only the fingerprint.
- Validate the CA chain / expiry / etc, and validate the fingerprint.
- Validate the CA chain / expiry / etc, ignore the fingerprint.
- A TOFU mode, with some management by fingerprint options.

No application that uses TLS should be considered completely
featured and security capable without fingerprint pinning functions.

The "SHOULD implement" loophole in 5.5.2 will end up with many OS
and implementations lacking such basic security feature option.

For some background reasons on why pubkey fingerprint pinning
implementations are now showing up in softwares that speak TLS,
and for sample code, and related infos, see the links...

https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html

https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
--pinnedpubkey <hashes | file>
Tells curl to use the specified public key file (or hashes) to verify the
peer. This can be a path to a file which contains a single public key in PEM
or DER format, or any number of base64 encoded sha256 hashes preceded by
'sha256//' and separated by ';'.
When negotiating a TLS or SSL connection, the server sends a certificate
indicating its identity. A public key is extracted from this certificate and
if it does not exactly match the public key provided to this option, curl will
abort the connection before sending or receiving any data.

Please note this option is rightly very specific covering only the
isolated pubkey, not the DER form of the entire "CA signed" cert
(ie: not the typically referenced coverage of "openssl x509 -fingerprint").
This allows additional adaptability to some cert environments.

Complete fingerprint implementations need both modes: pubkey, and cert DER.

Also note the use of sha-256, not the broken and now deprecated sha-1,
sha-3 could function as a backstop.

When fully implemented, fingerprint pinning enables a local admin and
user environment of more flexible certificate validation service cababilities
and security model hardening when subject to various third party things
and adversaries like...

- Environment of rogue / forced / spy MITM CA's, TLS termination / proxy
cloud MITM, VPN / overlay / WiFi networks MITM, etc.
- Annoying "expired" certs awaiting tax revenue from their captured audience.
- Assigning pinned trust to intermediate CA's such as Lets Encrypt, Google,
and corporate schemes, to let edge server certs they sign be freely
rotated and or freshly signed without need to update pin.
- Avoid need to update pin every "expiry" period.
- Avoid CA's by using cert owners publicly available and out of band self
certified hash attestations found on keybase, social, observatories, PGP, etc.
- As mentioned above, optionally in combination with other CA / expiry / etc
checks, or ignoring the CA altogether.
- CRL checks are a massive metadata privacy and user monetization
leak that some users might not want exposed to.
- Pinning one or both of: pubkey (herein) and or CA (openssl x509 -fingerprint)

Another very useful security feature to have is a trust on first use TOFU
mode that stores, pins, and subsequently validates against those fingerprints,
similar to SSH model. This is useful for both known comms partners such as
client-server model, and in more distributed group or even p2p applications
to help keep things a bit more locked down by default.

Defense (like this pubkey fingerprint pinning) in depth... you can use it :)

References (obviously TLS_1.3 is todays version to use)...

https://www.netcraft.com/internet-data-mining/ssl-survey/
https://www.ssllabs.com/ssl-pulse/
https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/
https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-internet-standard/
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://tools.ietf.org/html/rfc8446

https://github.com/OWASP/www-community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.md
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md

https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a31198d/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
https://github.com/curl/curl/blob/51fde337471c9125e7bf425e7ce0a0bf53691992/docs/TODO#L728

---

From: "Black, David" <[email-masked]>
Date: Mon, 30 Mar 2020 13:40:48 +0000

This looks interesting - is there a BCP (Best Current Practice) RFC or similar reference on what MUST/SHOULD to be implemented and how implementers ought to think about this to make good choices?  Or is there one being prepared?  For example, such a document ought to cover the tradeoffs among the four validation options, and how a safe default be chosen.   In general, this looks like a good direction as trust anchors and trust anchor management have always been a weak point in the web PKI

The OWASP pages are a good start, but leave revocation for future work and are weak on certificate replacement - in particular, the comment that the  "application would need to be updated regularly" appears to punt the underlying app validation problem upward to the app store operators (e.g., to defend against a rogue app that accesses the server via an MITM proxy server), which doesn't mesh well with "An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs".  Some dependence on the app store operator may be unavoidable for first-use.

Thanks, --David

> -----Original Message-----
> From: nfsv4 <[email-masked]> On Behalf Of grarpamp
> Sent: Sunday, March 29, 2020 5:49 PM
> To: [email-masked]
> Subject: [nfsv4] TLS Fingerprint Pinning Needed
> 
> 
> [EXTERNAL EMAIL]
> 
> https://owasp.org/www-
> community/controls/Certificate_and_Public_Key_Pinning
> https://github.com/OWASP/www-
> community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.m
> d
> https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a3119
> 8d/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Mon, 30 Mar 2020 10:49:39 -0400

Hello!

> On Mar 30, 2020, at 9:40 AM, Black, David <[email-masked]> wrote:
> 

I agree with David that this seems like excellent guidance for
implementations of RPC-TLS.

However, I don't see how it directly effects the protocol described in
draft-ietf-nfsv4-rpc-tls, as that document simply defines a STARTTLS
mechanism. I'm trying to understand what textual changes might be needed.
I'm guessing some adjustment of the Security Considerations section? Or
would we make a recommendation for certificate pinning only in protocols
that consume RPC (eg NFS)?

Note that without an RFC or other published standards-like document to
reference, I don't see that direct mention in our Standards Track
documents would be possible.

--
Chuck Lever