of Hanno Becker
Sent: Wednesday, March 11, 2020 2:36 PM
To: Christopher Wood ; tls@ietf.org
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
Thanks Eric, Martin and Chris for your input!
For the record: I withdraw my claim that there's an issue with handshake
message
on behalf of Christopher Wood
Sent: Wednesday, March 11, 2020 1:37 PM
To: TLS@ietf.org
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
Thanks for raising this issue and for the discussion, folks!
Given that endpoints *process* handshake messages in sequence, thereby
> >
> > 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.
> >
> >
chine duplication.
>
> Happy to hear your thoughts.
>
> Cheers,
> Hanno
> ----------
> *From:* TLS on behalf of Martin Thomson <
> m...@lowentropy.net>
> *Sent:* Wednesday, March 4, 2020 11:32 PM
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Gap
ine duplication.
Happy to hear your thoughts.
Cheers,
Hanno
From: TLS on behalf of Martin Thomson
Sent: Wednesday, March 4, 2020 11:32 PM
To: tls@ietf.org
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
Option A please. Multiple state
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
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