Removed dtls_close() from sock_dtls_sesion_destroy() since dtls_reset_peer() includes it already, when no close_notify was sent.

This looks reasonable - is there any drawback to merging this?

• (-) Possibility of truncation attack
• (-) Enforces this decision

• (+) sock_dtls_session_destory() does what it states with this PR

Nonetheless, it should be noted in the documentation before merge. I don't know from any more drawbacks by merging this. This does not fix the root cause, and there are still situations which lead to a not successful handshake we cannot address right now. To fix those, we need to refactor this completely.

Just to mention one situation we still do not address right now:

When we close a session, send the close_notify and immediately free the peer, but the remote peer does not receive this notify: In this case, the session is still active for the remote peer but for us, it is closed and cleaned up. If we now try to re-connect to this device, the success depends on the functionality of the used DTLS stack of the remote. If it supports re-establishing a session even when the session is already established from the device's perspective, all is fine, but if not...no chance until the other device wipes this session.
E.g. tinyDTLS does not support this, while californium/scandium supports it.

But again: This is a problem even without this PR.

Maybe add a comment about the shortcomings of this solution, but if it's better than the status quo, I don't see a reason not to merge it.

Maybe @obgm can also have a look?

Thanks @miri64 for bringing this to my attention. I agree with @janosbrodbeck in his assessment of the situation and the benefits and risks of merging this PR.

Note that tinydtls has had some changes recently, especially eclipse-tinydtls/tinydtls#53 which changed the close_notify alert level from fatal to warning. IMO this has no direct effect on the issue that dealt with in this PR. I also recommend updating pkg/tinydtls soon (there are a few important PRs under review that I also recommend waiting for, though).

I've added a note to the function documentation about the force reset. And I removed the draft state now.

Let me ask about the motivation to "close" the session:

When/why is that done?

• at the end of a communication phase, in order to pause/end communication for longer?
• in order to execute a new handshake to overcome some NAT issues (and bugs in DTLS server side implementation according RFC6347 - 4.2.8. Establishing New Associations with Existing Parameters) ?

The reason for this question is simple:

• yes the close should work proper and not cause additional trouble
• but, much more important: the server sides must implement 4.2.8!

The close may get lost, and so doesn't really help. 4.2.8 is in my opinion the only right way to do it.
For tinydtls I therefore prepared PR89 to fix the 4.2.8 behavior.

(In my Californium - Interoperability Tests it seems, that only mbedtls does 4.2.8 proper, openssl, gnutls and tinydtls (without PR 89) fails.)

Possibility of truncation attack

I'm still very confused about that and UDP. e.g. Wiki

SSL 2.0 used the TCP connection close to indicate the end of data. This meant that truncation attacks were possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL 3.0 fixed this problem by having an explicit closure alert).

There is just nothing as a TCP FIN for UDP. So, any references, what that attack means for UDP?

Yes, 4.2.8 is a crucial problem part here. With this workaround, we can run into the problem that we force close a session and cannot re-establish the session with the same peer until the other side timeouts/resets the session on their side. I mentioned this problem in comment #16422 (comment). To be honest, I consider 4.2.8 as a MUST and not a SHOULD for a DTLS stack, especially when used on constrained devices.

But this is and was a problem even without this workaround, since we do not get informed by the API right now if the closing was successful (= ACK from the remote part). In the case closing was unsuccessful, it could make tinyDTLS unusable in the long run without noticing by the application.

This workaround should never stay forever, it's only supposed to be a temporary solution for clients, so they don't become unusable over time if the close_notify is not ACK-ed.

To be honest, I consider 4.2.8 as a MUST and not a SHOULD for a DTLS stack,

:-) :-) :-) I always read MUST, I overseen the SHOULD ... :-) :-) :-)

This workaround should never stay forever, it's only supposed to be a temporary solution for clients, so they don't become unusable over time if the close_notify is not ACK-ed.

Yes, agreed. But even with a working "close_notify", everyone must be aware, that dtls-server, which don't implement 4.2.8 are always a bad choice. Assuming NATs, your "ip-endpoint" may have even been used by a other peer without close before.

There is just nothing as a TCP FIN for UDP. So, any references, what that attack means for UDP?

That's actually a good question, what this means for UPD. I've taken the truncation part directly out of the TLS RFC. I'm honestly also too little in the picture, what it takes for truncation attacks all to effectively exploit.

I wrote a e-mail to the tls-mailing list.
Maybe that brings some more light.