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

[Benjamin Kaduk <[e-mail]>]

On Thu, Apr 16, 2020 at 05:31:08PM -0400, Chuck Lever wrote:
> 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.

FWIW, SAAG seems to have found a consensus position that at this point new
protocols should assume 1.3 or newer.  A properly configured TLS 1.2 is not
known to be broken (and thus probably okay to allow for existing
protocols), but improper configurations of TLS 1.2 have significant
weaknesses.  So sticking with 1.3 is quick and easy and gets to a
known-secure baseline (and, if I might add, a well-designed protocol that
benefitted from extensive review and formal analysis during its
development).

In short, I expect the text in question to sail through the IESG.

-Ben