[netconf] TLS 1.3 and pre-shared-keys and raw-public-keys (was: More complications)

[Kent Watsen <[e-mail]>]

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