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