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/1604Yes, 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 <cont...@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 discussionI'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 <cont...@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 <cont...@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 <cont...@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
