Option A please. Multiple state machines. It's unavoidable in any case. If you generate your own post-handshake message and then have to respond to post-handshake authentication, there will be two concurrent exchanges. We already require acknowledgment for both request and response in a two-way exchange. Since 2 is a member of the third class of numbers (0, 1, ∞), we might as well deal with the full implications of that.
Handling this is fairly simple though. We can recommend limiting to only one active transmission at a time. And if implementations have an especially low tolerance for concurrency they can close connections. On Thu, Mar 5, 2020, at 01:19, Hanno Becker wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
