<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thx for all this clarification.<br>
</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> For example, how will the user configure the list of available PSKs?</pre>
</blockquote>
Regarding PSK API from other libraries : <br>
</p>
<p><b>AdvancedPskStore</b> from Scandium 3.x which is not so
straight forward to use mainly because it supports async request :
<a class="moz-txt-link-freetext" href="https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java">https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java</a></p>
<p><b>PskStore</b> from Scandium 2.x is more simple to understand
but no async way to request PSK :
<a class="moz-txt-link-freetext" href="https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java">https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java</a><br>
<br>
<b>PSKKeyManager</b> 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.<br>
-
<a class="moz-txt-link-freetext" href="https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java">https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java</a><br>
-
<a class="moz-txt-link-freetext" href="https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java">https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java</a><br>
Note that this class is deprecated in concrypt : I tried to get
more about this : <a class="moz-txt-link-freetext" href="https://github.com/google/conscrypt/issues/1197">https://github.com/google/conscrypt/issues/1197</a><br>
</p>
<p><b>TlsPSKIdentityManager </b>is very simple and very limited API
from Bouncy Castle :
<a class="moz-txt-link-freetext" href="https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java">https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java</a><br>
</p>
<p _d-id="25"><span _d-id="4312" class="--l --r sentence_highlight">Note
that most of them would probably have been thought with (D)TLS
1.2 in mind. </span><span _d-id="4315"
class="--l --r sentence_highlight">I don't know if this is
adapted for (D)TLS 1.3.</span></p>
<p></p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Well, for AES-CCM a pull request would have been nice :)</pre>
</blockquote>
I'm not so familiar with JSSE API/SunJSSE provider design for now.
Do you think AES-CCM is a good candidate to start ? <br>
I guess if I want to try to help on this, I need to have a look at
: <a class="moz-txt-link-freetext" href="https://openjdk.org/guide/">https://openjdk.org/guide/</a> (and also Contribution agreement)<br>
Oh and working on JSSE when it's time to build/running tests is
there a more simple way than building/testing whole JDK ?</p>
<p>Simon<br>
</p>
<div class="moz-cite-prefix">Le 15/03/2024 à 13:16, Daniel Jeliński
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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:
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240">https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240</a>,
but the producers and consumers aren't defined.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Which kind of help do you need 🙂 ?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:contact@simonbernard.eu"><contact@simonbernard.eu></a> napisał(a):
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:contact@simonbernard.eu"><contact@simonbernard.eu></a> 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
</pre>
</blockquote>
</blockquote>
</body>
</html>