Re: [nfsv4] TLS Fingerprint Pinning Needed

grarpamp <grarpamp@gmail.com> Wed, 08 April 2020 05:48 UTC

Return-Path: <grarpamp@gmail.com>
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 309093A0DD2 for <nfsv4@ietfa.amsl.com>; Tue, 7 Apr 2020 22:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3bg5ZkHtwLd1 for <nfsv4@ietfa.amsl.com>; Tue, 7 Apr 2020 22:48:39 -0700 (PDT)
Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D035F3A0DD1 for <nfsv4@ietf.org>; Tue, 7 Apr 2020 22:48:39 -0700 (PDT)
Received: by mail-io1-xd42.google.com with SMTP id m4so5919475ioq.6 for <nfsv4@ietf.org>; Tue, 07 Apr 2020 22:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Tmg8KZbV+ssBOXPS0CLm/L03V0JTQ6+S5thUvuQ7frI=; b=arb6vuUqkdk3qVhhduD9CU1ohUIrsnzCT4/9DomxbmUgfOOQuNTGEtnrDqxUQcUq07 FMQVLil5l4vWlMLFbGX7Qrvl8wEPO+nLr24X9J2lTTv2JHWmgaaJ7RcgxrKtwiqNFocV d76Sxno7lJa/6Dvz/Fn0TUeT+ho/wiyoUCF3bgzJCHPsUqK7l3E6lqYLn6dLXMlfCjTy 5Z5Ikt34jrcE7ZLuvoybZcIVstL5OJ57b4/TNNIWyn3dLp0fZLgy9C9QTjvS+lOtW4xF inlKwiVEhh7mQEc6DgGyQh/GO+B6Y+K/AxXezisAffrbREbvitN9JAP4cUQemVmfMcXm cerw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Tmg8KZbV+ssBOXPS0CLm/L03V0JTQ6+S5thUvuQ7frI=; b=LH//0xfPSL1yNFgbaD4ysZpbrGJTYSzRJx9Dmh2+ppzNgK6lICVOcFHaHT0kM7cizR KKvIaAFTj8JDw380eQo4uSx1r9zmo5V5FNaBIHXwRR6rVjYWmsGnl5iZJDwXXkTIwjEg TY1joWKrq/GwbegowbayiFUggGYIcOERCmdRwIsiD3zhlOm5Ty0ii1hSdAxCHZBhvlmK A48UkIxMJERIzihdj7ilaYA6Q6QBriFHPEHc4NMmUpfv9cUhSk16/izwJt0phtmxTdIE hE3qb9H9zI3U1spploPnIXdUV+Ukk6mI5mf0EMoPXg32ZH87ZmamL+3P3uhrbXXPe1Aa EN5A==
X-Gm-Message-State: AGi0PuZmCDAgBfrPwtb6brLiOEA5PTD9e5xaX/WPaYc81SKD3eqrbsCv 3jiOr7Lzw1LJIDnz6cTob5CLoLFPSIAgjTurf3sQ8mcK
X-Google-Smtp-Source: APiQypJk8I10YSWS2UtQB1D5YPC8CR1Ai1X1bll+kSWee0dHbBtPvVb45pBjgxWbDQp5RTejM4cRAoeAaqOT9tPrDAA=
X-Received: by 2002:a5d:8d90:: with SMTP id b16mr5258250ioj.93.1586324918520; Tue, 07 Apr 2020 22:48:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:bc7:0:0:0:0:0 with HTTP; Tue, 7 Apr 2020 22:48:37 -0700 (PDT)
In-Reply-To: <MN2PR19MB40451B5CBE13E7A19D9C0B1183CB0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <CAD2Ti2_Wmqgtm4iRTtoqVKPk8JJw+nP-rim2NjZWa=FDFbK5Bw@mail.gmail.com> <MN2PR19MB40451B5CBE13E7A19D9C0B1183CB0@MN2PR19MB4045.namprd19.prod.outlook.com>
From: grarpamp <grarpamp@gmail.com>
Date: Wed, 08 Apr 2020 01:48:37 -0400
Message-ID: <CAD2Ti2_eRXuCCK6C=hfa5eticmdmEGYr-TBZH_M_n3kqFGn7+g@mail.gmail.com>
To: nfsv4@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/fjr-cd82wKHlsSPLLg-xayny-c8>
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: Wed, 08 Apr 2020 05:48:41 -0000

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