Re: [nfsv4] TLS Fingerprint Pinning Needed

Benjamin Kaduk <kaduk@mit.edu> Sun, 12 April 2020 01:04 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0D33A1B61 for <nfsv4@ietfa.amsl.com>; Sat, 11 Apr 2020 18:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDHKbSS0WZcs for <nfsv4@ietfa.amsl.com>; Sat, 11 Apr 2020 18:04:03 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0E13A1B60 for <nfsv4@ietf.org>; Sat, 11 Apr 2020 18:04:02 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03C13vQF007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Apr 2020 21:04:00 -0400
Date: Sat, 11 Apr 2020 18:03:57 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: grarpamp <grarpamp@gmail.com>
Cc: nfsv4@ietf.org
Message-ID: <20200412010357.GK88064@mit.edu>
References: <CAD2Ti2_Wmqgtm4iRTtoqVKPk8JJw+nP-rim2NjZWa=FDFbK5Bw@mail.gmail.com> <MN2PR19MB40451B5CBE13E7A19D9C0B1183CB0@MN2PR19MB4045.namprd19.prod.outlook.com> <CAD2Ti2_eRXuCCK6C=hfa5eticmdmEGYr-TBZH_M_n3kqFGn7+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD2Ti2_eRXuCCK6C=hfa5eticmdmEGYr-TBZH_M_n3kqFGn7+g@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Prgjy-ICdiO96lNfDLvMpwJxr7c>
Subject: Re: [nfsv4] TLS Fingerprint Pinning Needed
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Apr 2020 01:04:05 -0000

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.

On Wed, Apr 08, 2020 at 01:48:37AM -0400, grarpamp wrote:
> On 3/30/20, Black, David <David.Black@dell.com> 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.

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

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

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.

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

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

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

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

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

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.

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

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