[Bug]: DTLS Message Sequence Number Equality Non-conformance

[bathooman]

Version

5.3.0

Description

Configure Options

./configure --disable-asm --enable-singlethreaded --enable-dtls --enable-dtls-mtu --enable-psk --disable-extended-master --prefix=$(pwd)/build --enable-static --enable-opensslextra --enable-debug

Expected behavior

The DTLS 1.2 RFC (Errata ID 5186) specifies two requirements regarding the equality of the message sequence number:

1- Equality of the message sequence number in CH0 and HVR:

In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the record sequence number in the ClientHello as the record sequence number in its initial ServerHello.

2- Equality of the message sequence number in CH2 and SH:

In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the message_seq in the ClientHello as the message_seq in its initial ServerHello.

Actual behavior

According to our tests, these two requirements are not satisfied in WolfSSL 5.3.0. For example, if one changes the CH0.mseq to 64, the server still responds with 0 in the HVR.mseq field. Similarly, if one changes the CH2.mseq to 0, the server responds with 1 in the SH.mseq field. I attached the Wireshark log for both scenarios in the following.

witness.zip

[ejohnstown]

I believe that wolfSSL is misbehaving here, but not in the way you are describing. I believe that wolfSSL should be ignoring the client hello with the message_seq number of 64.

I believe that the errata indicated is incorrect. Note that it conflicts with section 4.2.2 of the RFC. The message_seq number should start at 0, always.

I am going to make sure that the server ignores client hello messages that do not start with 0 or 1 with a correct cookie.

[bathooman]

Hello,

Actually, we had an interesting discussion on that with one of the TinyDTLS developers. Please take a look at these two issues: 1- https://github.com/eclipse/californium/issues/1620 2- https://github.com/eclipse/tinydtls/issues/72

[ejohnstown]

This should be fixed at this point. If you force the client to start with any message_seq number, the server is using the client's hello for its message_seq number. Both count up as expected.

I also read the discussions you posted, and reread the DTLS RFC. While the RFC requires the client to start with message_seq 0, the server is going to be using whatever is in the client hello message, which should be zero. The server is unable to keep track of the client's message_seq number between messages until the client uses the correct cookie, so it doesn't know if it every received message_seq 0. The server can change its secret used to generate the client cookie value, and could change it between client hello messages, and the client could send a hello with a message_seq of anything depending on the timing. I believe the requirement to start with 0 is ensuring a sensical start of the number sequencing; the RFC does not require that the server check the client started at 0.

I believe the above PR will fix the issue. Thank you for the bug report.