Thanks Martin for your thoughts.

>  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.

Yes that's an instance of the second question b) which the post didn't further 
go into.

I'm not yet convinced that this situation unavoidably creates the need for 
duplicating state machines, though, and think that if possible we should avoid 
it for the sake of implementation simplicity.

Moreover, even if it is acceptable that state machines should be duplicated, it 
isn't clear (to me) how to logically separate them because they're all tied 
together by the use of the same global handshake sequence number. This creates 
non-trivial ambiguities like the following:

Imagine after the handshake the server requests post-handshake authentication 
while, simultaneously, the client initiates a key update. When the server 
receives the KeyUpdate, it assumes from the handshake sequence number that it 
is the reply to his CertificateRequest, and only when inspecting the type of 
the handshake message it'll notice the mismatch. Usually, a type mismatch would 
be treated as a protocol violation and lead to failure of the connection, while 
here, we'd need the server to drop the message or notice that it should fork a 
new state machine.

Note that this problem already exists, albeit in less prominent form, in DTLS 
1.2, where both sides may simultaneously trigger a renegotiation.

Thinking about it, it seems that the way to make this work is to segregate the 
part of the retransmission state machine which establishes in-order delivery 
via handshake sequence numbers, and to have the duplicated contexts one level 
higher. When a handshake message comes in, it would be trial-fed into all 
existing contexts, either until one of them accepts it after checking type and 
content, or potentially leading to the forking of a new context..

However, this asynchronous nature of handling multiple post-handshake messages 
is in conflict with the serialized nature of the handshake transcript used e.g. 
in the CertificateVerify message:

Imagine a post-handshake client authentication to happen interwoven with 
another post-handshake message from client to server. When the client writes 
the CertificateVerify, that would require the transcript of the entire 
handshake up until the CertificateVerify message. Assuming this should include 
all post-handshake messages, not just those belonging to the client 
authentication, this may lead to the situation where the server receives a 
CertificateVerify message with a transcript it cannot validate because it 
hasn't yet received all other authentication-independent post-handshake 
messages that went into the transcript.

Maybe I'm overcomplicating things, but as it stands it seems to me that the 
above are serious issues to be further discussed and clarified even if we 
accept state machine duplication.

Happy to hear your thoughts.

Cheers,
Hanno
________________________________
From: TLS <tls-boun...@ietf.org> on behalf of Martin Thomson 
<m...@lowentropy..net>
Sent: Wednesday, March 4, 2020 11:32 PM
To: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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

Reply via email to