Re: [nfsv4] TLS Fingerprint Pinning Needed

[Chuck Lever <[e-mail]>]

> On Apr 8, 2020, at 1:48 AM, grarpamp <[e-mail]> wrote:
> 
> On 3/30/20, Black, David <[e-mail]> 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.

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.


> It is difficult to say "MUST" or "SHOULD" or "MAY"
> regarding this fingerprinting business for NFS.

The OWASP links cannot be Normative references, true enough.


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

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.


> Maybe then leverage that effort into a BCP with other
> 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?


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

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