Key Missing Feature for IoT

Simon Bernard contact at simonbernard.eu
Tue Apr 9 13:24:09 UTC 2024 

Thx for detail answers.

> Yes. I don't want you to spend months on a contribution only to have 
> us decide it is not something we want to include in the JDK. 
I really appreciate that.
> Yes, but PSK introduces security issues that need to be considered. We 
> would have to be very careful about how we proceed and expose the 
> functionality if we decide to support it. 
I'm not sure to see security issue you have in mind. Do you have any 
resources to share about that ? 🙏

> Unfortunately, these are not decisions that can be made quickly. I do 
> understand that there are some desirable things missing from the JDK 
> DTLS implementation in order to better support IoT use cases, but I 
> ask you to be patient while we investigate and determine if this is an 
> area that we want to further invest in.
I understand. I didn't expect a short term solution but I just tried to 
see if I could help to improve this not so good situation for IoT Java 
Developer at mid/long term.

Note that reported features are needed for DTLS but for TLS too (except 
CID of course).

> Additional community data is always helpful. 
So I will try to collect more data.

Thx again for your time.

Simon

Le 09/04/2024 à 15:07, Sean Mullan a écrit :
> Hi Simon,
>
> On 4/8/24 10:12 AM, Simon Bernard wrote:
>> Hi Sean,
>>
>>    Thx for warning me about that.
>>
>>    I understand that maybe this is too soon for contributing code ? and
>> also that finally this not so sure that you want to integrate (D)TLS
>> feature that I mentioned previously as Key IoT features.
>
> Yes. I don't want you to spend months on a contribution only to have 
> us decide it is not something we want to include in the JDK.
>
>>    So not sure what should I do now. In my first message, I try to 
>> expose
>> why I think some (D)TLS feature are strongly needed in Java Eco System
>> if that platform want to target IoT use cases (at least at server side)
>> and why the current situation is not so good.
>>
>>    Here another example that show the "not so good" situation :
>> https://github.com/bcgit/bc-java/issues/1604
>
> Yes, but PSK introduces security issues that need to be considered. We 
> would have to be very careful about how we proceed and expose the 
> functionality if we decide to support it.
>
>>    Is there something that I can do to help you to make decision about
>> those topics ? (Or maybe you try to tell me politely to not have too
>> much hope on this because it's not the priority at all for you)
>
> Unfortunately, these are not decisions that can be made quickly. I do 
> understand that there are some desirable things missing from the JDK 
> DTLS implementation in order to better support IoT use cases, but I 
> ask you to be patient while we investigate and determine if this is an 
> area that we want to further invest in.
>
>>
>>    Maybe I should try to better summarize the situation and also collect
>> more use case and/or project that needs this kind of feature ? (Maybe I
>> should ask for feedback from Eclipse IoT community?)
>
> Additional community data is always helpful.
>
> Thanks,
> Sean
>>
>>    I don't know 🤷‍♀️, I'm a bit lost.
>>
>> Simon
>>
>>
>> Le 02/04/2024 à 20:57, Sean Mullan a écrit :
>>
>>> Resending; fixed some of the link numbers.
>>>
>>> Hi,
>>>
>>> Sorry for the delay in replying as I have been busy with other issues.
>>>
>>> Thank you for your interest in Java Security. Thank you Daniel for also
>>> helping out with answering some of the questions.
>>>
>>> As Daniel pointed out, there are currently Enhancements open for adding
>>> CCM and PSK support to the JDK [1, 2]. Although these seem like nice to
>>> have features, we have not done enough analysis to know how much effort
>>> it would take and whether it is important enough for the Java Platform
>>> to support with respect to other projects/enhancements we are working
>>> on, such as incorporating new APIs like KEM [3] and KDF [4] and
>>> forthcoming PQC crypto support.
>>>
>>> However, I want to stress that we don't just accept any contributions
>>> that you think are worthwhile. While we welcome contributions, we do
>>> advise newcomers to read through the OpenJDK Developer's Guide [5], and
>>> recommend working on smaller contributions and bug fixes and developing
>>> a track record of trust. When considering enhancements, it is important
>>> that the community, myself and other members of the Security Group [6]
>>> agree that there is enough demand for that feature and that it is
>>> something we would want to support in the Java Platform for years to
>>> come. Those discussions should occur on this list. We may also conclude
>>> that while we think it would be valuable, we are not ready to make a
>>> decision about proceeding, and instead file an Enhancement for now.
>>>
>>> I look forward to continuing this and other discussions on things you
>>> would like to see in Java Security.
>>>
>>> Thanks,
>>> Sean
>>>
>>> [1] https://bugs.openjdk.org/browse/JDK-8176395
>>> [2] https://bugs.openjdk.org/browse/JDK-8049402
>>> [3] https://openjdk.org/jeps/452
>>> [4] https://openjdk.org/jeps/8189808
>>> [5] https://openjdk.org/guide/#author-committer-reviewer
>>> [6] https://openjdk.org/groups/security/
>>>
>>> On 3/20/24 5:19 AM, Daniel Jeliński wrote:
>>>>> any recommendation or example of this kind of work?
>>>>
>>>> Check out these JEPs, the description section:
>>>> https://openjdk.org/jeps/329
>>>> https://openjdk.org/jeps/8245551
>>>> https://openjdk.org/jeps/8281710
>>>>
>>>> In the PSK case the main question is, how is the user going to
>>>> configure the keys?
>>>> Cheers,
>>>> Daniel
>>>>
>>>> wt., 19 mar 2024 o 16:36 Simon Bernard <contact at simonbernard.eu>
>>>> napisał(a):
>>>>>
>>>>>> Well I think AES-CCM is a decent candidate to start.
>>>>> OK, I will probably take time to see if this is something within my
>>>>> reach.
>>>>> (I have limited time by week to give on that and not an expert on 
>>>>> this
>>>>> topic, so this will be mid/long term task)
>>>>>
>>>>>> Regarding PSK API, if you could put together a more complete 
>>>>>> proposal
>>>>>> of the API changes, together with an example of how this would look
>>>>>> from the API consumer side, this would be a good starting point 
>>>>>> for a
>>>>>> discussion
>>>>> I'm not sure a mail is a right way to do that, any recommendation or
>>>>> example of this kind of work ?
>>>>> Eventually I can write some code/documentation in a personal github
>>>>> repository.
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>> Le 18/03/2024 à 09:59, Daniel Jeliński a écrit :
>>>>>> Well I think AES-CCM is a decent candidate to start. If you 
>>>>>> choose to
>>>>>> work on this, you'll need to add support for AES/CCM to the JCE 
>>>>>> first.
>>>>>> Most of the code is already there: AES is implemented, CTR and 
>>>>>> CBC are
>>>>>> implemented, AEAD mode is implemented, so it's probably just a 
>>>>>> matter
>>>>>> of wiring these things together, and adding some known-answer tests,
>>>>>> which you can find here:
>>>>>> https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, you'll need the Oracle Contributor Agreement before you can
>>>>>> contribute code to the JDK. Once you have it, you can open a PR. Use
>>>>>> 8176395 in the PR title. The guide contains the instructions for
>>>>>> running selected tests only.
>>>>>>
>>>>>> Regarding PSK API, if you could put together a more complete 
>>>>>> proposal
>>>>>> of the API changes, together with an example of how this would look
>>>>>> from the API consumer side, this would be a good starting point 
>>>>>> for a
>>>>>> discussion. I know this is a lot to ask, but this is necessary to 
>>>>>> make
>>>>>> progres on the PSK.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>> pt., 15 mar 2024 o 16:43 Simon Bernard <contact at simonbernard.eu>
>>>>>> napisał(a):
>>>>>>> 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
>>>>>>>

More information about the security-dev mailing list