Add separate stateless processing for client_hello of epoch 0.

[boaks]

The PR is on the top of some other pending ones.
If at all merged, it is intended to be merged after these PRs.

Use the record and message sequence numbers of that client_hellos for
either sending a hello verify request or starting the handshake on the
server side with sending a server_hello.

The function of a HELLO_REQUEST is unclear and therefore not considered.
In some scopes a HELLO_REQUEST is only used for associated peers to
trigger a rehandshake (handshake executed within an previous encrypted
association, epoch > 0), and some scopes seems to handle also
situations, where either no previous association is required or the new
handshake is executed in epoch 0. That may be clarified either before or
after this change.

Signed-off-by: Achim Kraus [email protected]

[boaks]

Together with the other PRs #91, #92, #94, this PR provides now a redesign and cleanup for processing CLIENT_HELLO in epoch 0 and removes some stuff, which seems for me to be work-arounds.

I removed the rudiments of the HELLO_REQUEST in epoch 0.
If really someone complains, it may be introduced again, then with details on how that should be processed.

[obgm]

Thanks. May I ask you to change the spelling of DTLS messages in the commit message and in code comments in alignment with RFC 6347 (i.e., camel case: ClientHello, HelloRequest, Finished, etc.)?

[boaks]

Sure. I'm on it.

[boaks]

Done.

Do you prefer that CaMel also in the c-documentation?

[obgm]

Yes, please.

[boaks]

The comments should be fixed.

Let me know, if there is more editorial work to do. I will be back in the later afternoon :-).

[mrdeep1]

If I try using a bad PSK, the server fails to decrypt the Finished, which is fine. As there is no response to the 'bad' Finish the client retries sending the stuff from epoch 0 and then the Finished again in epoch 1.

The previous code reports

WARN Wrong epoch, expected 1, got: 0
WARN Wrong epoch, expected 1, got: 0
WARN Wrong epoch, expected 1, got: 0

and the new code

WARN The message sequence number is too small, expected 4, got: 1
WARN The message sequence number is too small, expected 4, got: 2
WARN The message sequence number is too small, expected 4, got: 3

As the server has done a ChangeCipherSpec and moved into epoch 1, should the server be continuing with the stateless processing for epoch 0?

As the Finished cannot be decrypted, there is no way of determining what the actual handshake is, but we know that it is in the new epoch as a handshake with a small record sequence number. Should we just drop this 'bad' record (as does OpenSSL) or send back an alert (as does GnuTLS - Bad Record MAC)?

[boaks]

I'm not sure, if I understand the scenario.

The "stateless" end with a ClientHello with a verified cookie.
After that, there is a peer.
Is it possible to see the wireshark capture?

[mrdeep1]

Sure - abstracted an example out of my test suite which gives slightly different results to what I reported above.
pr_89-1.pcap.zip

Server key was 12345678 , client key 87654321

Coap-Server log

Jun 29 18:35:21 WARN decryption failed
Jun 29 18:35:23 WARN The message sequence number is too small, expected 3, got: 2
Jun 29 18:35:23 WARN expected ChangeCipherSpec during handshake
Jun 29 18:35:23 WARN decryption failed
Jun 29 18:35:27 WARN The message sequence number is too small, expected 3, got: 2
Jun 29 18:35:27 WARN expected ChangeCipherSpec during handshake
Jun 29 18:35:27 WARN decryption failed
Jun 29 18:35:35 WARN The message sequence number is too small, expected 3, got: 2
Jun 29 18:35:35 WARN expected ChangeCipherSpec during handshake
Jun 29 18:35:35 WARN decryption failed
Jun 29 18:35:46 WARN decryption failed
Jun 29 18:35:59 WARN decryption failed
Jun 29 18:36:01 WARN The message sequence number is too small, expected 3, got: 2
Jun 29 18:36:01 WARN expected ChangeCipherSpec during handshake
Jun 29 18:36:01 WARN decryption failed
Jun 29 18:36:05 WARN The message sequence number is too small, expected 3, got: 2
Jun 29 18:36:05 WARN expected ChangeCipherSpec during handshake
Jun 29 18:36:05 WARN decryption failed
Jun 29 18:36:13 WARN The message sequence number is too small, expected 3, got: 2
Jun 29 18:36:13 WARN expected ChangeCipherSpec during handshake
Jun 29 18:36:13 WARN decryption failed
Jun 29 18:36:19 WARN decryption failed

The "stateless" end with a ClientHello with a verified cookie.
After that, there is a peer.

Agreed, however the code for case DTLS_CT_HANDSHAKE: in dtls_handle_message() no longer checks that the handshake is in the right epoch and so goes on the report the The message sequence number is too small, expected .

[boaks]

As the Finished cannot be decrypted, there is no way of determining what the actual handshake is, but we know that it is in the new epoch as a handshake with a small record sequence number. Should we just drop this 'bad' record (as does OpenSSL) or send back an alert (as does GnuTLS - Bad Record MAC)?

I'm not sure, if "GnuTLS - Bad Record MAC" is intended. At least for Californium there was a discussion about that PSK-failures and in that context TLS-IETF. There we decide " just drop this 'bad' record (as does OpenSSL)".

[boaks]

my test suite

That's not in the tinydtls repo, or?
(I was already asking me, if there are more tests ...).

[mrdeep1]

No, it is not in the tinydtls repo.

I have built up a regression test suite for libcoap over time for testing out different functionality and using different (D)TLS libraries with good/bad keys/certs etc. Diffs are then done for actual against expected. When using valgrind, things grind on for hours.....

Unfortunately, it is very dependent on the host OS, versions of underlying (D)TLS libraries that were would be too many false positives if it was to became part of the libcoap repo.

[boaks]

Unfortunately, it is very dependent on the host OS, versions of underlying (D)TLS libraries that were would be too many false positives if it was to became part of the libcoap repo.

OK. Good to know, that there are more tests.

[boaks]

I checked the GnuTLS behavior, it closes on the retransmission of flight 5. So the first flight 5 seems to be ignored.

Even in the Californium discussion on 2018, I wasn't totally convinced , what the best behavior will be. Anyway, usually to systems are used with the "right credentials", so I don't care too much about the wrong ;-).

[boaks]

My feeling is, "alert or not", is not really changed by this PR (hope I'm right.)
But by other PRs before, I guess #91 .

[mrdeep1]

Prior to #91, Decrypt Error is returned when processing the Finished. This PR (which includes #91) changes the message that is reported.

RFC5246 says

   decrypt_error
      A handshake cryptographic operation failed, including being unable
      to correctly verify a signature or validate a Finished message.
      This message is always fatal.

But agree that RFC6347 effectively states that Alerts should not be sent.

I am not sure that check_finished() will ever get called if the wrong keys are used as it is not possible to decrypt the Finished and so there is no way of working out the handshake type (other than the clue of epoch change and small sequence no).

[boaks]

I am not sure that check_finished() will ever get called

That protects against "manipulated handshake messages", e.g. on-path-attacker.
If extended master secret is use, this will happen really rarely.

[boaks]

And using RPK changes the possible failure as well. There the encrytion may work more often, but manipulated handshake message may get detected.

[boaks]

Yes, please.

The c-documentation is updated to use CaMeL. I added some more information about the "stateless phase" (which ends with receiving a ClientHello with a valid cookie). I adapted the function names of the affected funtions to a pattern xxx_0_yyy, in order to easier detect them (the other difference is the ephemeral_peer instead of a peer).

[obgm]

@boaks Thank you, this looks good to me. I am not sure if the two commits should be squashed before merge. Do you have an opinion on that?

[boaks]

I am not sure if the two commits should be squashed before merge.

I would do so.

Though this PR together with #91 obsoletes #85, @mrdeep1 is that also OK for you?

[mrdeep1]

Fine by me.

[boaks]

OK, I squash and push.

[obgm]

A few minor nits, otherwise I think it is ready for merge.