Re: [netconf] More complications

I think we are overlooking that the ietf-tls-client/server models are not solely for NETCONF protocol, e.g., the RESTCONF CLIENT/SERVER, SYSLOG, and PCEP modules also import the TLS modules.  The desire to support PSKs and RPKs in the TLS modules is not (yet) for the NETCONF WG.

That said, I’m beginning to want to remove the support for them if it holds up publication.  To be clear, we’re waiting to determine how best to model TLS 1.3 support while maintaining TLS 1.2 support.  I’ll ping Henk again.

K.

> On Jun 15, 2021, at 12:22 PM, tom petch <ietfc@btconnect.com> wrote:
> 
> From: netconf <netconf-bounces@ietf.org> on behalf of Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: 15 June 2021 13:18
> 
> 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.
> 
> <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
> 
> 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.
>> 
>> 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
>> 
>> 
>> On 15.06.21 13:36, tom petch wrote:
>>> From: Kent Watsen <kent+ietf@watsen.net>
>>> Sent: 14 June 2021 15:27
>>> 
>>> [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)...
>>> 
>>> <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
>>> 
>>>> Tom Petch
>>> 
>>> Kent
>>> 
>> 
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> 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/>
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf