Key Missing Feature for IoT

Fri Mar 15 15:43:10 UTC 2024

Thx for all this clarification.

>   For example, how will the user configure the list of available PSKs?
Regarding PSK API from other libraries :

*AdvancedPskStore* from Scandium 3.x which is not so straight forward to 
use mainly because it supports async request : 
https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java

*PskStore* from Scandium 2.x is more simple to understand but no async 
way to request PSK : 
https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java

*PSKKeyManager* from Concrypt is a more JSSE oriented API (no async 
too). I also understand that this API is available when coding for 
Android but I think there is a drawback a client is not able to select 
Identity based on InetSocketAddress of destination.
  - 
https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java
  - 
https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java
Note that this class is deprecated in concrypt : I tried to get more 
about this : https://github.com/google/conscrypt/issues/1197

*TlsPSKIdentityManager *is very simple and very limited API from Bouncy 
Castle : 
https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java

Note that most of them would probably have been thought with (D)TLS 1.2 
in mind. I don't know if this is adapted for (D)TLS 1.3.

> Well, for AES-CCM a pull request would have been nice :)
I'm not so familiar with JSSE API/SunJSSE provider design for now. Do 
you think AES-CCM is a good candidate to start ?
I guess if I want to try to help on this, I need to have a look at : 
https://openjdk.org/guide/ (and also Contribution agreement)
Oh and working on JSSE when it's time to build/running tests is there a 
more simple way than building/testing whole JDK ?

Simon

Le 15/03/2024 à 13:16, Daniel Jeliński a écrit :
> Hi Simon,
> Yes, the cipher suites in CipherSuite class are available in both TLS
> and DTLS by default. TLS 1.3 uses different cipher suites from TLS
> 1.2, so both protocols need to be updated.
>
> Regarding backporting to other versions of Java, backports are
> reviewed on a case-by-case basis. TLS changes are usually backported,
> but that's not a given.
>
> RPK is not implemented either; we have a declaration for the relevant
> handshake extensions here:
> https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
> but the producers and consumers aren't defined.
>
>> Which kind of help do you need 🙂 ?
> Well, for AES-CCM a pull request would have been nice :)
> For the other topics, I think we'd need to agree on the scope of the
> API changes needed. For example, how will the user configure the list
> of available PSKs? Will we need an API change? If not, which of the
> available APIs will we use to configure the keys?
>
> Cheers,
> Daniel
>
>
>
>
> pt., 15 mar 2024 o 11:58 Simon Bernard<contact at simonbernard.eu>  napisał(a):
>> 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 - TLS / DTLS -Profiles for the Internet of Things) :
>> "The use of raw public keys with TLS/DTLS, as defined in [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/29b37f08/attachment.htm>