DTLS_STATE_CLOSING may block session slots

[obgm]

RIOT-OS/RIOT#16422 correctly states that calling dtls_close() may result in a session held in state DTLS_STATE_CLOSING forever if no alert messages from the peer are received. Reasons for this might be dropped packets or a crashed/gone peer. A viable solution could include triggering cleanup (either through dtls_reset_peer() or dtls_destroy_peer()) after some timeout.

[boaks]

RFC5246 - 7.2.1. Closure Alerts

It is not required for the initiator of the close to wait for the responding close_notify alert before
closing the read side of the connection.

So, yes, that wait in DTLS_STATE_CLOSING may time out.

In my personal opinion, there are no good reason to use a Closure Alerts for DTLS at all.
The most definitions of RFC5246 (e.g. "required") will require to ACK/retransmit the Closure Alerts for RFC6347 in order to ensure, that the other peer received it.

RFC6347 - 4.2.7. Alert Messages

Note that Alert messages are not retransmitted at all

So, the means to ensure, that a "require" Closure Alerts is received by the other side, are not used.

• truncation attack
• continue to communicate without encrpytion
• "It is assumed that closing a connection reliably delivers
  pending data before destroying the transport."

Therefore all that hardly applies to DTLS without ack/retransmission, because without them, Closure Alerts are reduced to "may be received".

[obgm]

I think that closure alerts are still a good thing as an entity can react immediately on receipt of close_notify while it would have to rely on timeouts otherwise. Thus, these one-shot alerts are useful in the best case. The trade-off taken was apparently between stale connections and truncation attacks.

[boaks]

I guess, the question is the use-pattern.

If DTLS is used in a "time boxed session" way, then the Closure Alerts and new (resumption) handshakes for the next time makes sense. (With resumption, only the association keys could be freed, the master secret is still kept for resumption. So the benefit of saving resources may not be that large.)

If DTLS is used for "mid-term communication" in order to have less state for communication as CoAP may offer, then handshakes are used e.g once a day or week, and encrypted messages are exchanged without a prior handshake. That's mainly a question of the expected communication behavior of the application.

[mrdeep1]

I likewise think that a closure alert makes sense when an app no longer wants to transmit. My leaning would be towards if nothing is heard back from the remote end RFC6348 4.2.4.1 for RFC6298's maximum timeout of 60 seconds, then drop the association to prevent stale connections.

I am not convinced that we need a closure alert when a re-negotiate handshake is being undertaken.

[boaks]

That 60s timeout is used during the handshake. It doesn't s apply to application records.
Anyway, sure you my use smaller timeouts for the association/session in order to free resources earlier, but then I would prefer to have this as option.

You may either execute frequently handshakes even for only a couple of application bytes, or the associations are used for longer. Therefore DTLS CID helps a lot.

(In Californium the implementation only cleans-up stale associations, when the resources are required for new association. The experience with that is not too bad.)

[boaks]

I am not convinced that we need a closure alert when a re-negotiate handshake is being undertaken.

Using closure alert is not (longer) required in order to resume a session with an abbreviated handshake, not to mix up with re-negotiate handshakes.

RFC6347

Figure 1 : full handshake (using 6 flights, including a key-exchange, maybe with certificates). If that full handshake is execute over an existing association (epoch > 1, requires to keep the ip-address), then it's called a re-negotiation handshake (at least, in my understanding)

Figure 2 : abbreviated (resumption) handshake (using 3 flights, no key-exchange, no certificates). Execute not encrypted (epoch 0), may use a new ip-address. Currently not implemented in tinydtls.

[mrdeep1]

(In Californium the implementation only cleans-up stale associations, when the resources are required for new association. The experience with that is not too bad.)

The only caution here is that one needs to be careful about what is stale - immediately after sending the closure alert, or after a time when there there is no response etc.

[boaks]

The close removes the association but keeps the session.
Always the last recently used session is removed, if that gets required for new sessions.
Sending or receiving (successfully pass the MAC filter) will renew the recently used.
Additionally there is a "stale connection threshold", which protects recently used sessions from being removed for new ones.

My intention to mention that was to give some insides in different ideas without too frequent handshakes.

(Let me add: we assume, Californium runs on larger cloud-vms. With a couple GB RAM it's easy to have 1 000 000 sessions without too much trouble.)

[boaks]

Just to mention:

Sometimes "close" is used to overcome failures in RFC6347 - 4.2.8. Establishing New Associations with Existing Parameters.

So, FMPOV, sure, close should not cause additional trouble, but it's also no solution for broken 4.2.8.
Therefore PR #89. Without that, a new ClientHello of epoch 0 gets filtered out by:

Jul 06 09:22:06.622 DEBG * [::ffff:127.0.0.1]:5684 <-> [::ffff:127.0.0.1]:49790 (if1) DTLS: received 84 bytes
Jul 06 09:22:06 DEBG dtls_handle_message: FOUND PEER
Jul 06 09:22:06 DEBG got 'handshake' epoch 0 sequence 0 (84 bytes)
Jul 06 09:22:06 ALRT No security context for epoch: 0
Jul 06 09:22:06 INFO decrypt_verify() failed, drop message.

second_hs.pcapng.gz

[boaks]

truncation attacks.

I'm still very confused about the term 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?

[boaks]

Truncating TLS Connections to Violate Beliefs in Web Applications

Suppose a user initiates a wire transfer to Charlie’s Angels using the following

HTTP request:POST /wire_transfer.php
HTTP/1.1Host: mybank.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
amount=1000&recipient=Charlie%27s_Angels

Further suppose that the request is fragmented by TLS
as follows: “POST [...] recipient=Charlie” and“%27sAngels”. In this setting, an adversary can make a transfer to Charlie, rather than the intended recipient, simply by dropping the second (and crucially the last) fragment (e.g., by closing the underlying TCP connection after the first fragment is delivered).

All that, makes no sense for UDP / DTLS. Any packet may be dropped, the close doesn't imply, that "all previous" are processed. In my opinion, that must be clearly handled in layers above (e.g. coap blockwise with clear indication, when it's ready).

[mrdeep1]

The server has started to send Charlie in packet A followed by Angels in packet B. Client sees packet A, knows that it is getting a response and sends close alert as it will no longer be transmitting. Client may update Charlie with information rather than update Charlie+Angels if client does not wait for B and server's close alert signalling end of response.

A higher layer has to assume that data is presented in a contiguous fashion and any error recovery is handled by a lower layer. In the case of CoAP Block-Wise block arrival is lock stepped in than block N+1 can only arrive after the arrival of block N which then requests block N+1.

[boaks]

I try to understand, but failed ...

server                                client
package a       ------->
                         <-------      close
package b      -------->

Client may update Charlie with information rather than update Charlie+Angels if client does not wait for B and server's close alert signalling end of response.

I don't get that. May be you can try to express that in package sequences as above.

A higher layer has to assume that data is presented in a contiguous fashion and any error recovery is handled by a lower layer. In the case of CoAP Block-Wise block arrival is lock stepped in than block N+1 can only arrive after the arrival of block N which then requests block N+1.

I don't understand the attack. Does the client accept a "message" only contain package a?
That isn't the case for blockwise, or?

I'm mixed up ...

Truncation will only work, if the upper layer doesn't protect from that.
But I can't see, that a close can help in anyway.
Assume, the close has record seqn n, then there is no way to ensure, that record n-1 is not dropped, with or without close. not in the DTLS layer. A layer above will fail to retransmit a message, because records n+1 are dropped.

In TCP, the messages leaving that TCP layer are ordered and complete (and retransmittted, if not). With that, receiving the close over TCP ensures, that all previous TCP-data is received as well (that are the TCP grants).

And in UDP there are no such grants. That must be implemented in layers above.
And my conclusion is therefore:
"close" can't prevent from truncation attacks, but an upper layer must.