[secdir] Secdir early review of draft-ietf-nfsv4-rpc-tls-03

[Derrell Piper via Datatracker <[e-mail]>]

Reviewer: Derrell Piper
Review result: Not Ready

Reviewer: Derrell Piper
Review result: Not Ready

I reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents entering the IESG.  These comments
are directed at the security area director(s).  Document editors and WG
chairs should treat these comments like any other last call comments.

This draft is entitled, "Remote Procedure Call Encryption by Default",
except it does not define this.  It instead discusses opportunistic RPC
encryption using TLS (DTLS), encryption that might be used if the sun,
moon, and stars align, and likely only if you're running one of two NFS
implementations mentioned in this draft, which exclude most existing NFS
servers on the Internet today and is incompatible with Linux (pp. 13).

To some extent, this draft simply defines a new enum in ONC RPC, named
AUTH_TLS.  It completely handwaves all code changes in RPC and NFS to
support TLS, PKI, GSS-API, or DNSSEC.  It contains no pseudocode, just
RFC2119 MUST, MAYs, and SHOULDs.

pp. 5, Discovery

"The mechanism described in this document interoperates fully with RPC
implementations that do not support TLS. The use of TLS is automatically
disabled in these cases."

Hence, Not Ready.

I have great sympathy for wanting to try to make it possible to use TLS
by default in new NFS servers that support it, however even then, I
think this draft falls short.  It seems self-contradictory at times, and
seems to continue to default to off, not on, which is exactly what
RFC7258 says we ought not be doing anymore.

Or maybe it doesn't intend to say this, since Token binding and TLSA are
mentioned in Security Considerations, but optional, so it kinda does.
So, defer to the ADs.

pp. 6, Discovery

"Once the TLS handshake is complete, the RPC client and server will have
established a secure channel for communicating.  The client MUST switch
to a security flavor other than AUTH_TLS within that channel, presumably
after negotiating down redundant RPCSEC_GSS privacy and integrity
services and applying channel binding."

What are the code changes?  GSS-API is subtle, please explain.  Are
there really no TLS or DTLS changes for any of this?

pp. 6, Discovery, STARTTLS discussion

ONC RPC person needed.  The AUTH_NONE and NULL RPC text is of concern.

pp. 7, Authentication

"If authentication of either peer fails, or if authorization based on
those identities blocks access to the server, the client association
SHOULD be rejected."

MUST be rejected.

pp. 7, Authentication

"Once a TLS session is established, the server MUST NOT utilize the
client peer's TLS identity for the purpose of authorizing individual RPC
requests."

That's a curious statement to end a section on Authentication with.  At
least justify that statement.

pp. 8, TLS Requirements

"Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL."

Considering this is retrofit security for a legacy UNIX UID/GID
protocol, making PSKs OPTIONAL almost seems quaint here, but okay.

pp. 8, TLS Requirements

"Support for and negotiation of compression is OPTIONAL."  Noted.

pp. 9, Operation on Other Transports

"Transports that provide intrinsic TLS-level security (e.g. QUIC) would
need to be accomodated separatey from the current document.  In such
cases, use of TLS might not be opportunistic as it is for TCP or UDP."

"opportunitic" is misspelled, and I don't know what to make of this
sentence, but I have very partisan views on QUIC, so defer to the ADs.

I assume Section 5.1.3 is there for RDMA but it doesn't say anything.

pp. 11, X.509 Certificates Using Fingerprints

"Implementations MUST support SHA-1 as the hash algorithm for the
fingerprint.  To prevent attacks based on hash collisions, support for a
more contemporary hash function, such as SHA-256, is RECOMMENDED."

SHA-1's deprecated, right?  So we shoudn't be mandating SHA-1 in new
RFCs, right?  Defer to AD.

pp. 11 Pre-Shared Keys

"should be exposed" -> "SHOULD be exposed"

pp. 12, DESY, Hammerspace, and Linux

Why are these two implementations called out?  This section does not
give me confidence that this all interoperates, is it supposed to?

pp. 13, Security Considerations

Since absolute compatibilty with fielded insecure NFS is stated as a
requirement, the obvious downgrade attack is not only permitted, but
required.  Again, RFC7258 says that's no longer acceptable, doesn't it?
nAgain, defer to the ADs.

"Implementations must take care to accurately represent to all RPC
consumers the level of security that is actually in effect."  How?

pp. 14, Security Considerations for AUTH_SYS on TLS

"In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
RPC clients present authentication material necessary for RPC servers
they contact to have a degree of trust that the clients are acting
responsibly."

Hence, "if the sun, moon, and stars align."  Again, this is not in the
spirit of RFC7258.  And just to remind, AUTH_SYS doesn't make sense on
non-UNIX operating systems, but that perhaps is my partisan viewpoint.

In closing, there's two broad questions to consider:

1) Does this do no harm?

2) Does it improve security on the Internet in the spirit of RFC7258?

This is going to have to be much more detailed to convince me that it
does either of these things for any implementation other than DESY or
Hammerspace, and without other reference implemenatation in the BSDs or
a least some flavors of Linux, you can't say this broadly interoperable
either.  Distributed file systems are never easy, hence DCE/AFS, so
granted it's not an easy problem, but this is not ready to advance on
Standards Track, unless merely being interoperable with legacy code is
all we aspire to, and I sincerely hope it's not.

Perhaps this needle can be threaded and with appropriate configuration
by enterprising people, TLS can be configured with DNSSEC and GSS-API in
RPC and NFS and it will do something reasonable and secure, but I would
like to see at least some more comments from implementation experience
before I could recommend this advance.

Derrell