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

[Juergen Schoenwaelder <[e-mail]>]

Hi,

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.

/js

PS: And as I said before, if any updates to RFC 5539 are necessary to
    support NETCONF over TLS 1.3 properly, then we should spin RFC
    5539 and not deal with the definition of a transport mapping in
    the configuration document.

On Tue, May 25, 2021 at 09:56:52AM +0000, tom petch wrote:
> From: Kent Watsen <[e-mail]>
> Sent: 25 May 2021 00:16
> [CC-ing Gary in case he can help]
> 
> Hi Tom,
> 
> > I still think that the I-D lacks clarity about supported versions.
> >
> > Introduction
> > TLS Protocol [RFC5246]
> > Clearly this is TLS1.2 only
> >
> > Yes.   In keeping with the original intention (to reference just the current, not obsoleted, document), this should be updated to RFC 8446.   But I wonder if you think the document should reference all four documents (2246, 4346, 5246, and 8446) and then have DOWNREFS?
> 
> I didn’t get what you wanted to do here but, for now, I replaced that reference with this paragraph:
> 
>     Any version of TLS may be configured, including
>      <xref target="RFC2246"/>,  <xref target="RFC4346"/>,
>      <xref target="RFC5246"/>, and <xref target="RFC8446"/>.
>      Configuring obsolete protocol versions for use in production
>      networks is NOT RECOMMENDED.
> 
> <tp>
> I would still drop 1.0 and 1.1 entirely but see that others disagree.  As things stand, I do think that you need to differentiate between 1.2/1.3 and 1.0/1.1, the former being comprehensively supported, the latter not.  I do not have a good set of words for this but think that you need something in the Introduction to set expectations. You could add more details of 1.0/1.1 but I would see that as a retrograde step.
> 
> Tom Petch 
> 
> Tom Petch
> 
> 
> > I was all for ditching any mention of 1.1 and 1.0 if only for the extra complication.
> 
> By “was all for”, do you mean that you’re no longer?  That is, that “supporting” all versions is fine?
> 
> 
> 
> >   I no longer recall where 1.2 differs from its predecessors e.g. extensions incorporated in the base, signature algorithms, and it is probably overkill to find the relevant references for those older versions and adding them to the YANG as well but do think something needs adding in the body of the I-D to the effect that support for 1.0, 1.1 is partial, identity for the version number but not details of cipher suites, relevant RFC and so on.
> 
> Would you suggest adding said comment to the above paragraph?
> 
> 
> 
> > s.2
> > This model supports both TLS1.2 and TLS1.3
> > Ah, no, TLS1.2 and TLS1.3 but not TLS1.0 or TLS1.1
> 
> Do you mean that the sentence is incorrect because the model does support 1.0 and 1.1?  Perhaps simple remove the sentence altogether in light of the above new paragraph?
> 
> 
> 
> > s.2.1.1
> > Features
> > tls-1_0
> > tls-1_1
> > tls-1_2
> > tls-1_3
> > Ah no, it may not support 1.0 and 1.1 but it ........ for them but I know not what.
> 
> I don’t understand this comment.
> 
> 
> 
> > 2.2
> > an example for 1.1 and 1.2 but not 1.3; interesting.
> 
> That example is completely arbitrary IMO but, alas, it was created by Gary Wu, who is listed as a “Contributor”, but we haven’t heard from in a long time since...
> 
> 
> 
> > Reverse engineering the YANG I find that that 'Version 1.0 is supported', 'Version 1.1 is supported'.
> 
> Correct.  All the versions as “supported”; all but 1.3 are NOT RECOMMENDED.  Is this a problem?
> 
> 
> 
> > hello-params-grouping
> > Only 1.2 is referenced as indeed is repeatedly the case in the YANG modules
> >
> > Mmm I dunno!
> 
> Again, 1.2 *was* “current” before and so everything just pointed to it, assuming that it is a superset of 1.0 and 1.1?  We could just replace all refs to “1.2” with “1.3” and call it a day, but I don’t know if that would be technically accurate.
> 
> 
> 
> > I want the Introduction to set the scene which subsequent sections expand on and that I see as lacking.  Support fot 1.0 and 1.1 would, for me, catering for the different cipher suites that they have.
> 
> So we need to define additional ciphersuites for 1.0 and 1.1 or dump support for those protocol versions?
> 
> 
> 
> > In passing, I was wrong about public keys.  I misread the statement that only certificates and PSK are supported in TLS1.3, forgetting that certificate(255) is a public key!
> 
> Gotcha
> 
> 
> > Tom Petch
> 
> THANK YOU!
> 
> Updates can be found in https://github.com/netconf-wg/tls-client-server/commit/b94588b5a33c0852cfacbc415ca0a626bc1c5763.
> 
> K.
> 
> 
> 
> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

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