Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[Chuck Lever <[e-mail]>]

Following up -

> On Apr 12, 2020, at 6:30 PM, Craig Everhart <[e-mail]> wrote:
> 
> Is there a reason to require TLS 1.3?  TLS 1.2 isn’t old in many contexts.

My impression is that there are well-known security exposures with earlier versions of TLS and DTLS. Therefore new protocol specifications need to cite 1.3. I understood it to be a best security practice for protocol specifications to avoid enabling the consumption of known-to-be-insecure building blocks. I don't regard the TLS 1.3 requirement as any different from requiring SHA-256 instead of less secure ciphers.

rpc-tls has had two early SecDir reviews already, and there was no complaint about the TLS 1.3 requirement from those reviews. The one AD review comment relevant to this issue was that there should be a similar version requirement for DTLS, and so the next revision of rpc-tls will require DTLS 1.3 as well.

For those following at home, the text in question is this:

5.  TLS Requirements

  When peers negotiate a TLS session that is to transport RPC, the
  following restrictions apply:

  o  Implementations MUST NOT negotiate TLS versions prior to v1.3
     ([RFC8446] or [I-D.ietf-tls-dtls13]).  Support for mandatory-to-
     implement ciphersuites for the negotiated TLS version is REQUIRED.

How do others feel about this? Is the use of a current version of TLS merely an implementation quality issue? How have specifications of other upper layer consumers of TLS dealt with this issue?

My inclination, because we are already well-past WGLC for rpc-tls, is leave it to the IESG to adjudicate this issue.

--
Chuck Lever