Re: [netconf] netconf-tls wasRe: Summary of updates

[tom petch <[e-mail]>]

From: Juergen Schoenwaelder <[e-mail]>
Sent: 25 May 2021 15:40

On Tue, May 25, 2021 at 02:04:02PM +0000, Kent Watsen wrote:
>
> Hi Juergen,
>
> > RFC 5539 (published in May 2009) defines NETCONF over TLS and it is
> > very specific that it requires TLS 1.2 or future versions of TLS:
> >
> >   Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
> >   support the mandatory-to-implement cipher suite, which is
> >   TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to
> >   future versions of TLS; in which case, the mandatory-to-implement
> >   cipher suite for the implemented version MUST be supported.
> >
> > Given this, I do not think we need to consider TLS versions < 1.2
> > since there was never a specification for NETCONF over TLS versions <
> > 1.2 - a NETCONF over TLS 1.1 implementation is using a non-standard
> > transport.

> The tls-client-server draft is not exclusive to NETCONF.  For example, RESTCONF and PCE WG has a “peep-yang” draft...

Yep, I tend to forget this...

> That said, it seems Tom is saying that TLS 1.0 and 1.1 are effectively historic at this point (no longer used) and so support for those versions should be dropped for that reason?

If there are any features provided to configure historic versions of
TLS, then the features and identities for TLS 1.0 and 1.1 should
likely have a status obsolete and the feature and identities for TLS
1.2 may have status deprecated.

> The netconf-client-server doesn’t yet, but perhaps should, state
> that the tls-client-server’s draft support for 1.3 should be ignored
> until RFC 5539 is updated?

I guess someone (Tom?) should review RFC 5539 from the TLS 1.3
perspective to tell the WG if any changes are needed so that the WG
can take an informed decision whether an update of RFC 5539 is
necessary or whether what we have is good enough.

<tp>
Well, I tend to forget that RFC5539 is obsolete, obsoleted by RFC7589 which is X.509 certificate only; no PSK, no naked public keys.  My concerns with TLS1.3 mostly relate to PSK which allows data to flow before the handshake is complete, before authentication is complete, which is a problem for some applications as I mentioned before; but staying with X.509 authentication only for Netconf makes life simpler for a 7589bis, replace 1.2 by 1.3 and think about the extensions to see what may be needed.

Here however, with netconf-tls, the question is what the scope should be, to include or exclude TLS1.0/1.1 and how far to delve into PSK and early data; I assume that TLS1.3 must be covered in at least as much detail as TLS1.2, which was the starting point for my comments, where I saw lots of references for 1.2, very few for 1.3.. 

Tom Petch

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>