DTLS Context: Getting this error, "tls_post_process_client_hello: no shared cipher"

[pals-ucb]

Hello,
I got to work on this again this weekend. Made some progress in getting suitable certs generated by following the readme and the python code. I tested the DTLS client and DTLS server (written by us) using the regular RSA certs and it works fine.
I then switched to the certs that I generated following the guide to large extent.

Please see my questions for help at the end of this message.

 openssl req -new -newkey rsa3072_dilithium2 -keyout client.oqs.berkeley.edu_kyber768.key -out client.oqs.berkeley.edu_kyber768.csr -nodes

I generated rootCA and then signed the certs used by client and server using that, the same way I did for my earlier working tests.

Now, when I test the dtls server and client, I see the following error

DTLS Error: code: 0, error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

I did some debugging and added a client hello callback to see what ciphers I am getting, here is the dump of the
logs on the server side.

dtls_client_hello_cb: messages in sslv3 format.
dtls_client_hello_cb: number of ciphers from client: 56
dtls_client_hello_cb: c0 2c: name: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
dtls_client_hello_cb: c0 30: name: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
dtls_client_hello_cb: 0 9f: name: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.
dtls_client_hello_cb: cc a9: name: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256.
dtls_client_hello_cb: cc a8: name: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
dtls_client_hello_cb: cc aa: name: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
dtls_client_hello_cb: c0 2b: name: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
dtls_client_hello_cb: c0 2f: name: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
dtls_client_hello_cb: 0 9e: name: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
dtls_client_hello_cb: c0 24: name: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.
dtls_client_hello_cb: c0 28: name: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.
dtls_client_hello_cb: 0 6b: name: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.
dtls_client_hello_cb: c0 23: name: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.
dtls_client_hello_cb: c0 27: name: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.
dtls_client_hello_cb: 0 67: name: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.
dtls_client_hello_cb: c0 a: name: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA.
dtls_client_hello_cb: c0 14: name: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.
dtls_client_hello_cb: 0 39: name: TLS_DHE_RSA_WITH_AES_256_CBC_SHA.
dtls_client_hello_cb: c0 9: name: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA.
dtls_client_hello_cb: c0 13: name: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
dtls_client_hello_cb: 0 33: name: TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
dtls_client_hello_cb: 0 9d: name: TLS_RSA_WITH_AES_256_GCM_SHA384.
dtls_client_hello_cb: 0 9c: name: TLS_RSA_WITH_AES_128_GCM_SHA256.
dtls_client_hello_cb: 0 3d: name: TLS_RSA_WITH_AES_256_CBC_SHA256.
dtls_client_hello_cb: 0 3c: name: TLS_RSA_WITH_AES_128_CBC_SHA256.
dtls_client_hello_cb: 0 35: name: TLS_RSA_WITH_AES_256_CBC_SHA.
dtls_client_hello_cb: 0 2f: name: TLS_RSA_WITH_AES_128_CBC_SHA.
dtls_client_hello_cb: 0 ff: name: TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
dtls_client_hello_cb: 1 0: name: ?.
dtls_client_hello_cb: 0 90: name: TLS_DHE_PSK_WITH_AES_128_CBC_SHA.
dtls_client_hello_cb: 0 b: name: ?.
dtls_client_hello_cb: 0 4: name: ?.
dtls_client_hello_cb: 3 0: name: ?.
dtls_client_hello_cb: 1 2: name: ?.
dtls_client_hello_cb: 0 a: name: ?.
dtls_client_hello_cb: 0 16: name: ?.
dtls_client_hello_cb: 0 14: name: ?.
dtls_client_hello_cb: 0 1d: name: ?.
dtls_client_hello_cb: 0 17: name: ?.
dtls_client_hello_cb: 0 1e: name: ?.
dtls_client_hello_cb: 0 19: name: ?.
dtls_client_hello_cb: 0 18: name: ?.
dtls_client_hello_cb: 2f 0: name: ?.
dtls_client_hello_cb: 2f 1: name: ?.
dtls_client_hello_cb: 2f 3a: name: ?.
dtls_client_hello_cb: 2f 41: name: ?.
dtls_client_hello_cb: 2f 2c: name: ?.
dtls_client_hello_cb: 0 23: name: ?.
dtls_client_hello_cb: 0 0: name: ?.
dtls_client_hello_cb: 0 16: name: ?.
dtls_client_hello_cb: 0 0: name: ?.
dtls_client_hello_cb: 0 17: name: ?.
dtls_client_hello_cb: 0 0: name: ?.
dtls_client_hello_cb: 0 d: name: ?.
dtls_client_hello_cb: 0 5e: name: ?.
dtls_client_hello_cb: 0 5c: name: ?.
dtls_verify_cookie_cb: cookie_len: 16, cookie: ????j?sE;?Yz??.
DTLS Error: code: 0, error: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

1. I am wondering what are those IANA codes for which we don't have a CIPHER name?. Are these valid?
2. I see in the test code (oqs-test/test_tls_basic.py) that the code is passing a -groups to s_client with the kex algorithm like kyber512 for example. What is s_client doing with that? I am not able to figure that out from the s_client code. I am thinking that I must do what s_client is doing on my client side?
3. Any help or other approaches will help me to get this done by this week, hopefully.

[baentsch]

I am wondering what are those IANA codes for which we don't have a CIPHER name?. Are these valid?

We never had problems with cipher changes in TLS1.3 integration. But then again, (D)TLS1.2 is conceptually very different.

I see in the test code (oqs-test/test_tls_basic.py) that the code is passing a -groups to s_client with the kex algorithm like kyber512 for example. What is s_client doing with that? I am not able to figure that out from the s_client code. I am thinking that I must do what s_client is doing on my client side?

A pretty helpful high-level explanation of the groups concept (of TLS1.3) used is documented here. Also helpful may be the writeup of our integration here.

Any help or other approaches will help me to get this done by this week, hopefully.

FWIW, our integration took way more than a week -- and the (extension & groups) concepts of TLS1.3 (and accordingly the OpenSSL SSL layer code) matched QSC KEMs. In DTLS1.2 I personally don't see such match, so cannot see an obvious path forward for this. My recommendation would be to determine the conceptual integration you want to do first (how/where do you want to add QSC in the TLS1.2 message flow) and (only) then see how this might (or might not) be done with the code base.

[pals-ucb]

Would it be possible to have a 30 minute meeting with you and discuss how we can get to dtls 1.3 and openSSL 3.0 I can setup a meeting with you, if that is fine. I am in PST. /pals Mobile response

…

________________________________ From: Michael Baentsch ***@***.***> Sent: Saturday, August 5, 2023 10:15:50 PM To: open-quantum-safe/liboqs ***@***.***> Cc: pals-ucb ***@***.***>; Author ***@***.***> Subject: Re: [open-quantum-safe/liboqs] DTLS Context: Getting this error, "tls_post_process_client_hello: no shared cipher" (Discussion #1519) I am wondering what are those IANA codes for which we don't have a CIPHER name?. Are these valid? We never had problems with cipher changes in TLS1.3 integration. But then again, (D)TLS1.2 is conceptually very different. I see in the test code (oqs-test/test_tls_basic.py) that the code is passing a -groups to s_client with the kex algorithm like kyber512 for example. What is s_client doing with that? I am not able to figure that out from the s_client code. I am thinking that I must do what s_client is doing on my client side? A pretty helpful high-level explanation of the groups concept (of TLS1.3) used is documented here<https://wiki.openssl.org/index.php/TLS1.3>. Also helpful may be the writeup of our integration here<https://github.com/open-quantum-safe/openssl/wiki/Integrating-PQC-into-TLS-1.3>. Any help or other approaches will help me to get this done by this week, hopefully. FWIW, our integration took way more than a week -- and the (extension & groups) concepts of TLS1.3 (and accordingly the OpenSSL SSL layer code) matched QSC KEMs. In DTLS1.2 I personally don't see such match, so cannot see an obvious path forward for this. My recommendation would be to determine the conceptual integration you want to do first (how/where do you want to add QSC in the TLS1.2 message flow) and (only) then see how this might (or might not) be done with the code base. — Reply to this email directly, view it on GitHub<#1519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBTC5BALPLENRLB554KM4YDXT4SANANCNFSM6AAAAAA3FTJH7Q>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[baentsch]

PST is a bit far away for me (I'm at CET). Also, a discussion here may elicit more feedback than just mine (possibly also from the core OpenSSL team). What would be your topics of conversation/open questions anyway?

[pals-ucb]

Well, primarily we want to use DTLS 1.2 or 1.3 as a base to study Iot devices in PQC ciphers through OQS. I wanted to have a discussion to understand our next steps. Should we work directly with OpenSolaris team?. Would we get some direction from OQS team?. /pals Mobile response

…

________________________________ From: Michael Baentsch ***@***.***> Sent: Saturday, August 19, 2023 5:13:04 AM To: open-quantum-safe/liboqs ***@***.***> Cc: pals-ucb ***@***.***>; Author ***@***.***> Subject: Re: [open-quantum-safe/liboqs] DTLS Context: Getting this error, "tls_post_process_client_hello: no shared cipher" (Discussion #1519) PST is a bit far away for me (I'm at CET). Also, a discussion here may elicit more feedback than just mine (possibly also from the core OpenSSL team). What would be your topics of conversation/open questions anyway? — Reply to this email directly, view it on GitHub<#1519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBTC5BH5TAPV6F4UISLTHQTXWCUVBANCNFSM6AAAAAA3FTJH7Q>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[baentsch]

Should we work directly with OpenSolaris team?.

I would not know what OpenSolaris does in this context -- do you mean OpenSSL? If so, then Yes, the OpenSSL team would be the right place to have a discussion about introducing support for DTLS1.3.

Would we get some direction from OQS team?.

We'd be glad to help adding PQ support for DTLS1.3 but at this time have no suggestions how to enable this for DTLS1.2.

[pals-ucb]

My bad. I typed openSSL; however, auto correction changed it to OpenSolaris. I did not clearly reread the contents before clicking send. I connected with the openSSL team, and found the discussion on DTLS1.3. Looks like they are justing beginning some proposal on this front. I described my interests and have volunteered to help. Let me see how that goes. Here is that conversation: openssl/openssl#13900 /pals

…

On Aug 24, 2023, at 23:13, Michael Baentsch ***@***.***> wrote: Should we work directly with OpenSolaris team?. I would not know what OpenSolaris does in this context -- do you mean OpenSSL? If so, then Yes, the OpenSSL team would be the right place to have a discussion about introducing support for DTLS1.3. Would we get some direction from OQS team?. We'd be glad to help adding PQ support for DTLS1.3 but at this time have no suggestions how to enable this for DTLS1.2. — Reply to this email directly, view it on GitHub <#1519 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBTC5BAAQK2G72GSBN562B3XXA663ANCNFSM6AAAAAA3FTJH7Q>. You are receiving this because you authored the thread.

[baentsch]

This matches my understanding. OK to close the issue here until openssl/openssl#13900 is resolved?

[pals-ucb]

Yes. We can close this issue Thanks for explaining patiently and guiding me. Looking forward to work with you and OQS. /pals Mobile response

…

________________________________ From: Michael Baentsch ***@***.***> Sent: Tuesday, August 29, 2023 11:09:52 PM To: open-quantum-safe/liboqs ***@***.***> Cc: pals-ucb ***@***.***>; Author ***@***.***> Subject: Re: [open-quantum-safe/liboqs] DTLS Context: Getting this error, "tls_post_process_client_hello: no shared cipher" (Discussion #1519) This matches my understanding. OK to close the issue here until openssl/openssl#13900<openssl/openssl#13900> is resolved? — Reply to this email directly, view it on GitHub<#1519 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBTC5BDD7KIXV4PHNC2ZMJDXX3KLBANCNFSM6AAAAAA3FTJH7Q>. You are receiving this because you authored the thread.Message ID: ***@***.***>