Subject: Re: [nfsv4] TLS Fingerprint Pinning Needed

From: grarpamp <[email-masked]>
Date: Wed, 8 Apr 2020 01:48:37 -0400

On 3/30/20, Black, David <[email-masked]> wrote:
> 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?

Not aware of one, maybe the list knows of some more resources?
Would be good to have some more documents in the space.
In particular herein regarding fingerprinting... differentiating the
two different cert DER vs pubkey forms, their various features and
capabilities in real world cert schemes scenarios, and re MITM.

There is a general encryption proponent mandate RFC,
commensurate with Snowden events, the number escapes
at this moment.

Yes, more development of such a BCP as you mention regarding
TLS fingerprint capabilities, and TLS extent forward in general,
would be nice. That would then extend to many protocols
in a default guide of reference way as to what is possible,
including say NFS.

It is difficult to say "MUST" or "SHOULD" or "MAY"
regarding this fingerprinting business for NFS.
But it may be reasonable that 5.5.2 be expanded to mention
the two different fingerprint classes, the four modes, as reasonable
desireables. And to then reference out to the OWASP links at the
bottom of the RFC.

Maybe then leverage that effort into a BCP with other
application RFC groups regarding TLS.

> 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.

It is assumed, and guaranteed under public embarrassment
of news media, that revocation will results in a physical regen
and change of cert (triggering both cert DER and pubkey
hard physical swapouts). Thus revocation, and the whole
revocation "authority" repository CRL OCSP checks etc,
is not at all coming into an issue in this fingerprint context,
since they are entirely independant and fixed and local,
and detect and resolve all such revocation swaps by
very nature of fingerprint failure and fingerprint updates.

The "application being updated regularly" is of course a nice
option for such app shipping devs to do gratuitously for users.
But has no bearing on users subsequent needed capability
to pin whatever they want and feel is necessary independantly.

If I were an NFS users in particular infrastructures and risks,
I might want to pin the end server pubkey (or cert DER),
or intermediate instances of the same (leaving server cert
free to float) regardless of what my vertical or lateral silo,
or other peer model, or CA, or rogue, says to accept.

Is there a reasonable way to more strongly suggest implementation
of those two fingerprint methods, and even some of the four modes,
as options between server-client in the NFS TLS RFC?

---

From: grarpamp <[email-masked]>
Date: Thu, 9 Apr 2020 00:10:51 -0400

> There is a general encryption proponent mandate RFC...

One might also try full text RFC search for "fingerprint"
references in context of "TLS" (or the older "SSL").

The following incomplete list all in manner of spirit do
generally give rise and encourage the offering and enablement
of such security option sets in apps / protocols utilizing TLS...

Recommendations for Secure Use of Transport Layer Security (TLS)
https://tools.ietf.org/html/rfc7525
Pervasive Monitoring Is an Attack
https://tools.ietf.org/html/rfc7258
Privacy Considerations for Internet Protocols
https://tools.ietf.org/html/rfc6973
Certificate Transparency
https://tools.ietf.org/html/rfc6962
Strong Security Requirements for Internet Engineering Task Force
Standard Protocols
https://tools.ietf.org/html/rfc3365
Guidelines for Writing RFC Text on Security Considerations
https://tools.ietf.org/html/rfc3552
IETF Policy on Wiretapping
https://tools.ietf.org/html/rfc2804
IAB and IESG Statement on Cryptographic Technology and the Internet
https://tools.ietf.org/html/rfc1984

"It is the consensus of the IETF that IETF standard protocols MUST
make use of appropriate strong security mechanisms."

Privacy Requirements for IETF Protocols
https://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-01
   It is the consensus of the IETF that our protocols be designed to
   avoid privacy violations to the extent possible.

Handling Pervasive Monitoring in the IETF (perpass) (WG)
https://www.ietf.org/proceedings/88/perpass.html
https://www.ietf.org/mailman/listinfo/perpass

Not requiring app (NFS) spec implementations to have some options
for some of the previously noted modes of fingerprint checking to help
avoid some TLS MITM attacks, would seem to be in conflict with all above.

---

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

> On Apr 8, 2020, at 1:48 AM, grarpamp <[email-masked]> wrote:
> 

I don't think it's a "would be nice". Given the IETF's citation
requirements, if an NFS spec is to make compliance statements
about using TLS pinning there would first have to be Standards
Track documents that properly introduce pinning and cover
the security issues satisfactorily.

The high level requirement is the area experts within IETF have
to reach consensus about the general mechanism. Only after that
point, protocol architects are then permitted to cite that
consensus in their specifications.

In other words, I think David is gently suggesting the correct
starting point for making this happen.

> regarding this fingerprinting business for NFS.

The OWASP links cannot be Normative references, true enough.

> desireables. And to then reference out to the OWASP links at the

As a co-author of rpc-tls, I can get behind adding beefier
implementation guidance in Section 5.2.2. However since this
document has already gone through WGLC, I'd really like to have
a rough consensus about that level of change.

I'm working through the AD review comments this week, and can
propose some text on-list.

> application RFC groups regarding TLS.

To be clear: Pinning seems like good stuff and NFS should probably
be made to use it. IMO the nfsv4 working group is not the place
to initiate that work. Starting it here (or even in rpc-tls in
particular) is placing the cart before the horse.

We are required to have a BCP and/or generic RFCs first. In my
view, the advance work would be more appropriate coming from
the tls working group:

https://datatracker.ietf.org/wg/tls/documents/

Have you taken these ideas up with them?

> as options between server-client in the NFS TLS RFC?

The nfsv4 WG's speculative plan is to produce one or more NFS-
specific documents that would be able to provide this kind of
detailed requirement for implementations of NFS that use TLS.

To REQUIRE certificate pinning, the NFS document would cite RFCs
that are specifically about pinning and then describe how NFS
would use it.

Those RFCs have to be published first or at the same time as
the NFS documents that cites them. Those are the process rules.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 11 Apr 2020 18:03:57 -0700

Hello,

You seem to be starting from the premise that pinning by fingerprint is the
strongest security/authentication mechanism possible in many cases.  While
pinning is a useful element in the security toolbox, I don't believe it's
as widely appropriate as you seem to be arguing for, which I'll try to
clarify below.

> Would be good to have some more documents in the space.

I believe there is not such a document currently in the RFC Series.

> capabilities in real world cert schemes scenarios, and re MITM.

It is perhaps a useful mental experiment to consider pinning as an
incarnation of very selective choice of trust anchor.  Modern TLS stacks
allow for indicating that a non-root CA and even an end-entity (non-CA)
certificate are considered to be trusted as trust anchors, and thus the
pinning you desire can be implemented within generic PKI trust frameworks
as choice of a single specific trust anchor, the public key in question.
In IETF documents we essentially universally leave the deployment's
selection of trust anchor(s) as a matter of local policy, and thus it is a
bit out of character for us to be recommending specific trust anchors or
classes of trust anchor.  We provide robust security mechanisms and
describe how they can be safely used, but leave policy to others.

> commensurate with Snowden events, the number escapes

(That's the "Pervasive Monitoring is an Attack", RFC 7258, that you listed
in the followup.)

> desireables. And to then reference out to the OWASP links at the

I agree with David and Chuck that this is pretty clearly the wrong document
in which to do so.

> very nature of fingerprint failure and fingerprint updates.

I'm not sure I understand your point here.  You seem to be saying that
CA-driven revocation is orthogonal to key pinning, and thus that when a
revocation event occurs, the legitimate counterparty will generate a new
key (and fingerprint), with the resulting connection errors being detected
and used as a trigger to update local configuration.
But that doesn't make sense to me!  If there's a revocation event and
presumed key compromise, then the attacker that got the key can continue to
use it against the deployment that pinned that key until the configuration
is changed.  This seems to be ignoring the signal from the CA that
"something bad happened" and could lead to a long period of vulnerability.
It's far from clear to me that key pinning provides superior properties to
CA-based setups in the face of such revocation events.

> as options between server-client in the NFS TLS RFC?

I don't really think there's a reasonable way to do so, no.  The current
standards-track guidelines for verification of domain-based application
service identity with PKIX certificates for TLS (RFC 6125) lists various
ways that names can be encoded in certificates and discusses how to
validate those names (in the context of a given deployment's choice of
trust anchor(s), of course).  But the focus is clearly on *names*, not
keys, which is a rather different focus than the pinning you propose.
It would perhaps be compatible to focus on the choice of trust anchor and
the possibility to pin intermediate certificates, but this again starts to
stray into areas that the IETF historically leaves as a matter of local
policy.

In a follow-up you also noted:

% Not requiring app (NFS) spec implementations to have some options
% for some of the previously noted modes of fingerprint checking to help
% avoid some TLS MITM attacks, would seem to be in conflict with all above.

I disagree.  We have lots of examples of IETF protocols that comply with
the list of RFCs giving guidance on security practices, and fingerprint
pinning is hardly ubiquitous in those protocols.

-Ben

---

From: grarpamp <[email-masked]>
Date: Sun, 12 Apr 2020 05:34:34 -0400

> the premise that pinning by fingerprint is the
> strongest security/authentication mechanism possible in many cases.

It is certainly among the set of them that might be applied
in various ways depending on the users security model.

> describe how they can be safely used, but leave policy to others.

Allow to better define below the context as being in
supporting the presence of options for policies...

> CA-based setups in the face of such revocation events.

It is risky and then embarrassing to continue using a compromised
private key. The compromise is the preceding and defining element,
and rightly triggers a security rekey event. The rekey hash mismatch is,
the and only required, signal when a users application is watching the
fingerprint, if that is how the user configured their options.
This is independant, and if so chosen "orthagonal", from any assertion
or not as such by or to any CA signal crl scheme, that assertion being
at that point, equally the same as pinning check, a separate function
from the security compromise and restoration itself.
Fingerprints, "CA signals", other checks, are independant cases, and
can be combined in some users environments, provided they have
options to do so.
Further, many environments use CA only to avoid software CA nag
warnings and have little knowledge or care for CRL systems, and
many users have little knowledge or care to check them.
People also often try to trot out this false argument of relying "CA signal"
or revocation as some means to moot or demur the implementing of
fingerprinting options in the app code, or to avoid configuring them.
That is not the case.

As to NFS... in this suggestion, nfsv4-rpc-tls in 5.2.2
needs to REQUIRE all conformant implementations
to have fingerprint configuration OPTIONS for the user
to use as they deem appropriate. This does NOT
require users to use it, only that it be present
as option in conformant implementations.

If CA method of 5.2.1 is a REQUIRED security thing, then
similarly, so can fingerprint security OPTION things of 5.2.2 be.

If nfsv4-rpc-tls anywhere REQUIRES any things
of any conformant implementations, then so can it
require some fingerprint OPTIONS things.

If nfsv4-rpc-tls 5.2.2 is already specifying a
SHOULD-hint as to a "via"-form of SHA-256 being
over the cert-DER form (with or without including
reference to just what spec that is), it really must
also fairly provide a SHOULD-hint as to the "via"-form
of pubkey. That is probably simple enough, leaving
the four modes and other option combinatrics up
to the application teams, the possibility for such
potentially hinted in note in section 7.

External references are already possible by example
of URI list in 9.3. Additionally, perhaps something in
RFC5280 or similar could be noted or pointed to
as RFC5280 was noted and or pointed to in 5.2.1.

RFC's even have places available for further discussion
and strong words encouragement, such as section 7.

> fingerprint pinning is hardly ubiquitous in those protocols.

Unfortunately that is largely because fingerprint pinning is a
hardly understood black magic of additional TLS defence, in
depth, hardly mentioned, referenced, documented, implemented,
or educated on, etc. Most don't really understand MITM modes.
And with all the noise droning on about CA, $fees, "validation"
of corporate entites, advertising, who can blame them.
This issue is a similarly common copout / chicken egg to the
above CA CRL excuse for not creating fingerprint options.

Beneficial ubiquity can be fostered by more rfc's,
internet application docs, etc becoming a part of the
set of same that begins and further integrates more
mentions and supports for pinning options in their
various works.

It would suck to effort to add this TLS to NFS but
not enjoy some fingerprint pinning options along with it,
because, well, it was only a SHOULD, so your OS
skipped them resulting in less than featureful. Oops.

> stray into areas that the IETF historically leaves as a matter of local

Requiring pinning OPTIONS would enable this making of local
policy choices among such options. No options, no choices.
Users like having options and choices.

Best.