Key Missing Feature for IoT

Tue Apr 9 14:05:27 UTC 2024

On 4/9/24 9:24 AM, Simon Bernard wrote:
> 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 ? 🙏

Sure, here's a couple:

- https://www.rfc-editor.org/rfc/rfc9257
- 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf 
(see Appendix C).

--Sean

> 
>> 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
>>>>>>>>