Your environment.

• Version: 3.0.4
• Browser: We are using the embedded WolfSSL 5.6.0 on the Sequans GM02SP on Walter (https://www.quickspot.io)
• Other Information: We use pion/dtls as the encryption for a CoAP server for our cellular devices.

What did you do?

We are running a pion/dtls server and connect through cellular with the stack on the modem, which is WolfSSL 5.6.0. The WolfSSL stack aborts the handshake in flight4.

What did you expect?

I expected the handshake to work.

What happened?

After a lot of digging with Wireshark packet traces we have found and validated the issue. In the ClientHello message from the embedded devices there is no renegotiation_info extension and also no TLS_EMPTY_RENEGOTIATION_INFO_SCSV Signaling Cipher Suite Value:

In reply to the above ClientHello the pion/dtls library sends a ServerHello with an empty renegotiation_info extension.

RFC5746 section 3.6 states the following:

If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the
"renegotiation_info" extension was included, set the
secure_renegotiation flag to FALSE. In this case, some servers
may want to terminate the handshake instead of continuing; see
Section 4.3 for discussion.

o If the secure_renegotiation flag is set to TRUE, the server MUST
include an empty "renegotiation_info" extension in the ServerHello
message.

RFC5246 section 7.4.1.4 states the following:

An extension type MUST NOT appear in the ServerHello unless the same
extension type appeared in the corresponding ClientHello. If a
client receives an extension type in ServerHello that it did not
request in the associated ClientHello, it MUST abort the handshake
with an unsupported_extension fatal alert.

RFC5746 section 4.2 states the following:

When the ServerHello is received, the client MUST verify that it does
not contain the "renegotiation_info" extension. If it does, the
client MUST abort the handshake. (Because the server has already
indicated it does not support secure renegotiation, the only way that
this can happen is if the server is broken or there is an attack.)

When I read through merge request #314 I can see that the initial implementation from 16 February 2021 was correct and followed the RFC. But for some reason this was changed a day later to not follow the RFC an always return a renegotiation_info in the ServerHello.

My request would be to rollback commit 9890736 as this breaks clients that follow the RFC spec.