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

[tom petch <[e-mail]>]

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.