Subject: Re: [netconf] More complications

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Jun 2021 14:27:55 +0000

[CC-ing Henk, to whom a question is directed to below]

Hi Tom,

> Top posting a new and different issue.

Thanks for updating the subject line.

> server case psk references ServerKeyExchange and psk-identity-hint neither of which exist in TLS1.3.  The client sends an extension PreSharedKeyExtension which contains a list of identities from which the server selects one as selected-identity for which the identifier is uint16 indexing into the client's list. RFC8446 s.4.2.11.
> 
> The client description also needs amending.
> 
> TLS1.2 was extended to use tickets in this area to aid session resumption; these have now gone and been replaced by this extension.  I would not suggest adding support for tickets.
> 
> As I may have said before, TLS 1.3 is different.

Henk, could you help with these edits?   Support for PSK and raw public key were added to draft-ietf-netconf-tls-client-server per your request and, if memory serves me, didn’t you help me with the YANG update too?   I suppose what is needed is a either a “choice” statement (with cases for 1.2 and 1.3) *or* sibling-container statements (in case it’s necessary both are configured in case, e.g., the client sends one or the other)...

> Tom Petch 

Kent

---

From: tom petch <[email-masked]>
Date: Tue, 15 Jun 2021 11:36:29 +0000

From: Kent Watsen <[email-masked]>
Sent: 14 June 2021 15:27

Hi Tom,

<tp>
Or else drop support for PSK with TLS1.3 at this time because too little is known about it outside the use for HTTP.  I am starting to see I-D about how to use TLS1.3 with application X, even for HTTP,  and I think that such an I-D will be needed for many applications with or without PSK.

Tom Petch

Kent

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 15 Jun 2021 13:53:19 +0200

Hi all,

a fellow IETF'ler poked me to pay attention to this thread. Sorry for 
the latency.

Hm - dropping PSK support for TLS 1.3 seems to be leaving a bunch of 
implementations in the IoT space behind that are inching towards 
migration, currently.

How urgent is this? I can certainly massage the current YANG module, but 
(in theory) I am occupied by another SDO meeting this week.

Viele Grüße,

Henk

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Jun 2021 14:18:04 +0200

The way TLS is used with NETCONF is defined in RFC 7589. If any of
that needs clarification to properly support TLS 1.3, then we need to
revise RFC 7589. Defining the proper configuration knobs should follow
from that.

And as Kent reminds us, the scope of the TLS configuration draft is
much wider than just NETCONF over TLS. Hence, dropping support for
certain TLS 1.3 features, that may be essential in some use cases,
should be done with great care. (And lets keep in mind that dropping
standard configuration knobs just means that there are no standard
configuration knobs, it does not mean that a certain protocol feature
won't be used, it will just be configured using other non-standard
means).

/js

On Tue, Jun 15, 2021 at 01:53:19PM +0200, Henk Birkholz wrote:
> Hi all,
> 
> a fellow IETF'ler poked me to pay attention to this thread. Sorry for the
> latency.
> 
> implementations in the IoT space behind that are inching towards migration,
> currently.
> 
> How urgent is this? I can certainly massage the current YANG module, but (in
> theory) I am occupied by another SDO meeting this week.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 15 Jun 2021 15:06:47 +0000

Thanks Juergen and Tom.

Henk, thanks for poking in on this thread.  Given that it appears the PSK/RPK support in TLS 1.3 is work-in-progress, Tom’s suggestion to defer modeling the TLS 1.3 part of the model at this time makes sense to me - do you agree?

If so, then it seems that we should update the model now to have a “choice statement” or “sibling-container statements", adding “if-feature” statements as needed, and then just define the TLS 1.2 solution, enabling the TLS 1.3 solution to slide-in “perfectly” via a future effort.  

Could you (or maybe Tom) help us know if a “choice statement” or “sibling-container statements” is needed?  The answer may vary for the TLS-client vs the TLS-server...

K.

> On Jun 15, 2021, at 8:18 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: tom petch <[email-masked]>
Date: Tue, 15 Jun 2021 16:22:24 +0000

From: netconf <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 15 June 2021 13:18

<tp>
You wisely pointed out this before and then and now, I re-read RFC7589 and think that updating it will take some time and that I am unclear how much scope it gives us for the time being.

It only mentions TLS1.2 (of course) but does not prohibit other versions so arguably caters for some forms of TLS1.3.

It is very keen on certificates but allows for other suitable mutual authentication which could be taken to include PSK but would appear not to cater for deriving a username from a PSK (s.7) which suggests PSK is out of scope.  TLS regards a public key as a certificate which is fine until you need a subjectAltName  or some such from which to derive the username, which the RFC does so that would seem to be out of scope. 

It does not cover TLS keepalive (which netconf-tls does).

So, TLS1.3 with proper certificates would seem to be the only option.

Tom Petch

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Jun 2021 20:48:41 +0000

[tweaking the Subject line]

Hi Henk,

I just realized that I never replied to your question below regarding urgency.

It would be good to get a high-level response ASAP so that a quick-patch can be made that will pass the eminent SecDir review.

A more thorough response would ideally be "ASAP" also, but it is the case that this draft will remain open while a couple other drafts go through WGLC, so the hard-stop window is a few weeks out yet.

Thanks,
Kent

> On Jun 15, 2021, at 7:53 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
> 
> a fellow IETF'ler poked me to pay attention to this thread. Sorry for the latency.
> 
> Hm - dropping PSK support for TLS 1.3 seems to be leaving a bunch of implementations in the IoT space behind that are inching towards migration, currently.
> 
> How urgent is this? I can certainly massage the current YANG module, but (in theory) I am occupied by another SDO meeting this week.
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: tom petch <[email-masked]>
Date: Wed, 30 Jun 2021 08:49:06 +0000

Sent: 29 June 2021 21:48

Hi Henk,

<tp>
On IoT, there is an I-D on this 
draft-ietf-uta-tls13-iot-profile-01
which looks comprehensive and includes a statement about a plain PSK-based client but I am not clear that this covers the options.  It does cater for authentication by certificate followed by resumption with PSK with warnings about early data (which may be strong enough for a Security AD) but seems to skate over the case where no certificates are involved, in particular it makes no reference to the two TLS I-D about the use of PSK without certificates.  My understanding is that you need those two I-D to make PSK without certificates work and so the I-D is incomplete.  That apart, I think that it is the sort of TLS1.3 profile that the TLS WG expects to see for every application that uses TLS1.3 e.g Netconf must do something similar one day.

raw-public-keys are, to me, different, TLS1.3 simply treats them as another kind of certificate (although the UTA I-D does not) and so does not create similar issues.

Tom Petch

Thanks,
Kent

---

From: tom petch <[email-masked]>
Date: Wed, 30 Jun 2021 16:09:49 +0000

From: netconf <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 26 May 2021 17:12
From: netconf <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 26 May 2021 16:45
From: Juergen Schoenwaelder <[email-masked]>
Sent: 26 May 2021 12:53

This sounds like 'lets wait and see what comes out of the RFC 6125
revision' is the best approach for now.

<tp>
Oh dear; I got the wrong WG.  The 6125 update I-D exists and is in the UTA WG (which I am not subscribed to but saw a cross post thereof). It is quite short and is very much an updates, requiring the use of SAN, prohibiting CN-ID.   It was published on April 1st, 2021:-)

<tp>

Following on to this, 
draft-ietf-uta-rfc6125bis-00 
has now been submitted.   So far, the proposal is for the use of CN to be removed and the rules for the use of asterisk to be changed, although I do not yet see the former in the I-D -00!
Still time to wait and see!

As the I-D says, there is an issue tracker in the personal github of one of the authors.

Tom Petch

<tp>
WFM

I do have an element of FUD about this (as I have about TLS1.3) which hopefully will diminish with time.

Tom Petch

/js

On Wed, May 26, 2021 at 09:23:17AM +0000, tom petch wrote:
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: 25 May 2021 17:29
>
> On Tue, May 25, 2021 at 03:58:10PM +0000, tom petch wrote:
> >
> > 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.
> >
>
> So regarding a possible update of RFC 7589, what is needed?
>
> + Require TLS 1.3 (update section 8)
>
> Which extensions should one think about? Do you mean RFC 8773 or
> something else?
>
> <tp>
> It is more a question of going through 8446 s.4.2 s.9.2 to see what we want by way of an Application Profile.  Thus I would like to prohibit PSK but that prohibits session resumption which is fine by me but I have limited exposure to what the world is doing so may be it is not that simple.
>
> There is another problem which I see as larger and that is that the TAPS WG is revising RFC6125 and this leans heavily on that RFC and that might take a year or two to get revised.  I don't have a sense of where a 6125bis is going.
>
> Tom Petch
>
> /js
>
> --