Subject: Re: [nfsv4] testing of RPC over TLS

From: grarpamp <[email-masked]>
Date: Sat, 28 Aug 2021 03:31:39 -0400

On 11/27/20, David Noveck <[email-masked]> wrote:
> There is no way we can make the sort of changes in the existing RFC
> candidate that you propose, at this point.

Some of the cert / pin related sections do appear to have been
"changed" ie add/drop/edit after the first thread started, thus
changes did appear possible. The point of spirit being, these
sort of feature reqs can be added to implementation specs
especially since they don't affect the rpc protocol at all.
It's software pin checks on the TLS cert, not involving wire or
TLS negotiation / protocol / ciphersuite / aggreement / etc.
Nor are they difficult for implementations to code up for users.

> the document approved ... did not take the view [of security]

Placing trust in third parties such as CA's (many of which CA's are,
or are in, MITM active countries run by SpyVeillance Governments
upon their and other innocent citizens, including forcing civilian, edu,
bizcom, and other classes of users browsers to include SpyCA's in
their browsers, directly and intentionally for purpose of MITM spying.
Not to mention what happens when ISP's BGP's VPN's Tor's CloudFlare's
Apple's and so on get forced or abused to run MITM attacks on users)...
is not a wise thing to do. Every case is different, options are needed.

Also be wary of not doing a "thing" just because some lofty
"consensus" or high "interlocutors" are steering it off... plenty
of examples in history where even "trusted" steering was
proven to be security malicious. And since these "things" herein
are not protocol but instead mere command line options for
stricter security checks by the users, such steering arguments
are moot or could even be viewed as strangely suspect.
No offense intended of course.

This applies to all TLS applications and pub/priv-key secured
protocols in general, not just NFSv4 or HTTPS, thus each such
application should take note of these issues and features too.

Maybe IETF has a place where such general for-all aspects
of secured protocols are being worked too.

> It is possible for the working group to change its mind and start work on a
> revised RFC.   You can propose that to the working group.

Consider it hereby proposed. Whatever way helps give options
to users for pubkey and cert-DER hash pinning will be a fine
way. It is likely better to put it in global spec docs top-down,
than try to reach out to all the implementors bottom-up, ie
because your interop sessions will be more fruitful, consistent,
cross-capable and cross-checked that way from the get go as well :)

> Another
> possibility is to address these issues in an nfsv4-specific context (rather
> than in a general rpc context) as part of the anticipated RFC deriving from
> an eventual draft-ietf-nfsv4-security.    I'd appreciate it if you
> provided material regarding these (and other important) security issues
> that would fit in draft-dnoveck-nfsv4-security-needs.   I think it would be
> best if we incorporated all these before submitting
> draft-ietf-nfsv4-security-needs.

Agreed that RPC is not a good context, as pinning is not dependent
on RPC wire specs. It was posted Mar2020 to draft-ietf-nfsv4-"rpc"-tls
because that doc was already specifically mentioning such area of
cert checking abilities, before even those security option / guidance
sections got deleted from it. Thus at that time the local draft diff
here for those sections was no longer able to base off anything
towards becoming a posted submission for review.

If any of the draft docs below would also be a good place to put
the material reference and even the implementation features
MUST and or SHOULD designations, then that would be
helpful for the new NFSv4-TLS community of developers
and users as well...

draft-ietf-nfsv4-security
draft-dnoveck-nfsv4-security-needs
draft-ietf-nfsv4-security-needs

All of the background material needed for adding
pubkey and cert-DER hash pinning to whichever
drafts has already been posted (ie: links to code
examples [curl], rationales, etc) in the two threads
you may refer back to....

Subject: TLS Fingerprint Pinning Needed
Subject: testing of RPC over TLS

Perhaps those better at the draft-* flow and work than I could create
a section / diff in whichever are the relevant / suggested docs.

Or perhaps if there are implementors here working on the
OS's, they might find a way to bring it to their code / docs.

We want to encourage, herein, that implementors ensure that
options exist in their implementations for their users to
implement their own local policy choices (pinning checks)
as desired.

Hopefully everyone will be able to test, interop, and review
some implementations that provide pubkey and cert-DER
fingerprint hash pinning options for NFSv4-TLS before long :)

Cheers.