Re: [netconf] netconf-tls wasRe: Latest ietf-netconf-server draft and related modules

[Kent Watsen <[e-mail]>]

Hi Tom,


> I find this I-D confused about which versions of TLS are supported.  It is 1.0/1.1/1.2 or1.2/1.3 or 1.0/1.1/1.2/1.3 or 1.2 or ...
> This needs addressing and the text changed to match.

The “ietf-tls-common” module has features: "tls-1_0”, "tls-1_1”, "tls-1_2”, and "tls-1_3”.  Per this recent thread [1], my local-copy now has for all features except “tls-1_3” a comment in the “description” statement along the lines of "TLS 1.x is obsolete and thus it is NOT RECOMMENDED to enable this feature."

[1] https://mailarchive.ietf.org/arch/msg/netconf/dGGP4kQU8EnlcMVMq1ZZ0uAYBO0


> I suspect that the IESG will not accept any support for 1.0 or 1.1 given the existence of an RFC deprecating them and that this I-D should not go further than putting in place hooks with which an organisation could augment such support if they wanted to, but even that may be going too far.

Disagree.  It's one thing to say that a protocol is deprecated and another to say that the configuration for a still somewhat-widely used deprecated-protocol is deprecated.


> I wonder too about what forms of authentication are acceptable, something that has changed several times in the life of the I-D.  I do  not have a view of which are and which are not but think that guidance from the TLS WG or SecDir or Security AD would be useful now rather than later.

What is there to wonder about with regards to forms of authentication?  Saying they’ve changed several times is exaggerated - they changes only once, and that was to add support for “raw public keys” and “pre-shared-keys”, per request.  AFAIK, the auth mechanisms (the two just mentioned + X.509 certs) are the minimally viable set.


> In a similar vein, TLS 1.3 is keen to ship application data before the handshake is complete, before authentication has happened, which causes problems for applications which want the handshake and authentication to complete first.  I see NETCONF as being such an application and the I-D needs to address that, as it is being addressed by other WG.

Is that really true?  How is it not considered a security hole in the protocol?!  I agree that it’s undesirable, but it’s unclear what text could be added to the “tis-client-server”, “netconf-client-server” or “restconf-client-server” drafts to address this.  Please advise.

Thanks,
Kent