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

[tom petch <[e-mail]>]

From: Kent Watsen <[e-mail]>
Sent: 11 May 2021 18:11

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

<tp>
My comment is that in different places in the I-D there are references to different combinations of different versions of TLS so I am not clear that all four versions are supported.  If they are, as you suggest, then editorial changes are needed - look for example at all the places where RFC5246 is referenced - valid for TLS 1.2 but for the other versions of TLS? I think not.
</tp>

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.
<tp>
Well, time will tell.  I expect pushback from Security AD which I why I suggested getting secdir or some such to look now rather than when it has reached the IESG
</tp>

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.

<tp>
I do not know if TLS1.3 works with raw public keys - I have not seen that documented.

PSK support changes with TLS1.3.  Its prime use AFAICT is session resumption and there are now constraints on its use, such as not using a key with any other version of TLS ie one PSK for TLS1.2 (or earlier) and a different one for TLS1.3.  Also, a given TLS1.3 PSK should only be used with a single hash algorithm.  This may or may not be in the YANG module but needs a mention IMHO.

So yes, there are things to wonder about with authentication in TLS1.3 because it is so different.
</tp>

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.

<tp>
I am not sure which part of my post you are querying but yes, data ships before authentication is complete and the application must cater for that.  AFAICT the driver for this is HTTPS, or a number of large web providers, who want to improve the customer experience by eliminating round trips which creates a security hole which the application then has to plug.  This is no problem for HTTP but I think will be for most other protocols, such as NETCONF, but this is a general TLS problem so I think belongs in this I-D as a security hole.

EAP fell into the hole needing to know when authentication was complete and not realising that they could not tell with TLS1.3.  It was the IESG who spotted this and there is now an addition to EAP to tell it when the handshake is really complete as opposed to gone far 
enough to meet the needs of HTTPS.  draft-ietf-eap-emu-tls-13 gets it wrong, -15 fixes it, a topic of much discussion last December and January on the TLS list.

Tom Petch


Thanks,
Kent