Re: [TLS] Gaps in specification of DTLS 1.3 state machine

[Martin Thomson <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>