Key Missing Feature for IoT

[Simon Bernard]

Hi Daniel,

Thx for quick answer.

For PSK and AES, if this is added then this will be also for TLS ? (not 
only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this 
feature will be added, would they be available on next JDK version OR 
also old version ? (e.g. I know some recent security feature was 
backported in java8)

Today, I was looking at Raw Public Key support (RPK) and I understand 
this is not supported too. Am I right ?
RPK is also part of LWM2M specification and also refered in 
(RFC7925§Section4.3 <https://www.rfc-editor.org/rfc/rfc7925#section-4.3> 
- TLS / DTLS -Profiles for the Internet of Things) :
/"The use of raw public keys with TLS/DTLS, as defined in [RFC7250 
<https://www.rfc-editor.org/rfc/rfc7250>], is the first entry point into 
public key cryptography without having to pay the price of certificates 
and a public key infrastructure (PKI)."/

>   Help is welcome.
Which kind of help do you need 🙂 ?

Simon

Le 15/03/2024 à 11:38, Daniel Jeliński a écrit :
> Hi Simon, welcome to security-dev!
>
> You got the situation of DTLS right:
> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
> - connection identifier is not implemented, and not on the to-do list yet;
> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
> understand correctly, this one should be relatively easier to
> implement, using the implementation of the ChaCha20 cipher as an
> example (see JDK-8140466, JDK-8204192).
>
> It makes perfect sense to add these features to the OpenJDK. They were
> never high enough on the priority list to get implemented. Help is
> welcome.
>
> Cheers,
> Daniel
>
>
> czw., 14 mar 2024 o 17:31 Simon Bernard<contact at simonbernard.eu>  napisał(a):
>> Hi all,
>>
>> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>>
>> LWM2M is mainly based on coap and coap+tcp protocol.
>> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>>
>> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>>
>> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>>
>> My understanding, DTLS 1.2 was added but there is still no support of :
>>
>> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925§Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
>> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
>> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>>
>> If I missed something and one of those feature is already available let me know.
>>
>> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>>
>> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
>> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
>> There is also possibility to bind native library but this is not so easy and also have drawback.
>> All that solution sounds not so good...
>>
>> So do you think it could make sense to add this kind of feature in OpenJDK ?
>> Or Maybe there is already plan to add it ?
>>
>> (I hope this is the right place for this kind of question)
>>
>> Thx,
>>
>> Simon
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240315/23f4ad4e/attachment.htm>