Hi, [TL;DR] The DTLS 1.3 spec (draft 34) doesn't fully describe the retransmission state machine in the case of post-handshake messages, which requires clarification. For example, is it allowed to send multiple post-handshake messages without waiting for ACKs for the previous ones? If so, how is the retransmission state machine modeled for sender and receiver in this case? I'll describe and assess a few possible options, but I don't know the best answer, and so this post is mostly a request for discussion, hopefully resulting in some common understanding and clarification of the spec.
Details: The following cases need addressing: a) Is it allowed to send multiple post-handshake messages (e.g., multiple session tickets) without waiting for ACKs for the previous ones? If so, how is the retransmission state machine modeled for sender and receiver in this case? b) How should simultaneous sending/receiving of post-handshake messages be handled? The current retransmission state machine doesn't allow sending and receiving at the same time. Some thoughts on a) first: The spec mentions that post-handshake messages are treated as single-message flights. As such, the sender would enter WAITING state after sending the post-handshake message, and move to FINISHED on receipt of the corresponding ACK. This, however, forbids sending another post-handshake message in between, since sending isn't allowed in WAITING state. Option A: Fork state machine One could circumvent this by 'forking' the retransmission state machine for post-handshake messages, i.e. declaring their semantics as if there were multiple independent state machines for each outstanding post-handshake message. This essentially degrades the DTLS' ACK scheme to a per-message acknowledgement. I believe that such an approach is not in the spirit of the rest of the protocol and moreover significantly increases complexity and thereby comes at the danger of slower adoption and/or bugs. Moreover, it will significantly harden efforts for formal verification, which should be considered in light of previous efforts on TLS 1.3. Option B: Don't allow multiple post-handshake messages Forcing implementations to await an ACK before sending the next post-handshake message is a theoretical option which would allow to stick to the existing state machine. However, this significantly increases the latency of, say, the delivery of multiple session tickets, which is a valid use case. This is therefore not a convincing option, either. Option C: Merge consecutive post-handshake messages into a single flight. Another approach would be to treat multiple post-handshake messages as a single flight on the sender. That is, when the sender is in state WAITING after sending the first post-handshake message, and the user request to send another one, it moves into SENDING and then back into WAITING as usual, appending the new post-handshake message to the (so-far single-message) flight. How would that be handled on the receiver side? That's not entirely clear because a basic property of the TLS handshake that DTLS leverages now no longer holds: Namely, that both sides implicitly know and agree on the bounds of flights. Here, multiple post- handshake messages would be treated as a single flight on the sender, but the receiver doesn't know when the flight is over. How should this be handled? This is to be explored further. One way to address this would be the following: Option D: Add an 'end-of-flight' signal to handshake messages to allow dynamic-length flights. Recall that the handshake logic must inform the retransmission state machine about when a flight is over in the main handshake, allowing the state machine to transition accordingly. This signal, however, isn't explicitly conveyed to the receiver, because the receiver can figure it out for himself. As mentioned, this isn't true anymore for batched post-handshake messages. One simple way to deal with is to add an explicit 'end-of-flight' bit in the handshake header which informs the receiver about when a flight is over, in those situations where it's not clear from the context. This would allow to keep a single retransmission state-machine as-is while allowing for batched post-handshake messages such as multiple session tickets. Moreover, such a signal would be trivial to implement because it's already implicit in the main handshake. For the wire-format, we can discuss different options, but that's an orthogonal question to the issue of finding the correct conceptual approach. Happy to hear everyone's thoughts. It would be great if we could come up with some precise description of the state machine evolution for post-handshake messages that is both simple and supports batched post-handshake messages. Best, Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
