Re: [netconf] More complications

[Henk Birkholz <[e-mail]>]

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 <[e-mail]>
> 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
>