User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3
Mime-Version: 1.0
Message-Id: <f06035d2-5f46-4eed-95c4-88faf62f4253@www.fastmail.com>
In-Reply-To:
 <CABcZeBMKAyTBNCpEMZksZxv5PeJZPPQzykhE7ZNeZ366zLYpYw@mail.gmail.com>
References: =?utf-8?q?=3CAM6PR08MB331811E58E80173B1D74D8349B1C0=40AM6PR08MB3?=
 =?utf-8?q?318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?=
 =?utf-8?q?=3C0287f75a-015e-49eb-a052-cf7a53f03035=40www=2Efastmail=2Ecom=3E?=
 =?utf-8?q?_=3CAM6PR08MB33182017F0D9EA53A8B247DF9BE20=40AM6PR08MB3318=2Eeurp?=
 =?utf-8?q?rd08=2Eprod=2Eoutlook=2Ecom=3E?=
 <CABcZeBMKAyTBNCpEMZksZxv5PeJZPPQzykhE7ZNeZ366zLYpYw@mail.gmail.com>
Date: Wed, 11 Mar 2020 06:37:51 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tls/mIgk_u4GADo8qLg6CooI7iyww9o>
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
Precedence: list

Thanks for raising this issue and for the discussion, folks!

Given that endpoints *process* handshake messages in sequence, thereby p=
reventing any out-of-order processing issues raised earlier on this thre=
ad, the chairs think no further action is needed to address this comment=
.

Thanks,
Chris, on behalf of the chairs

On Thu, Mar 5, 2020, at 6:45 AM, Eric Rescorla wrote:
> Hanno,
>=20
> I do think you are overcomplicating things somewhat.
>=20
> You can't process handshake messages out of sequence even if they are
> received out of sequence (this is, of course, also the case in TLS,
> it's just that the resequencing happens at the TCP layer).. You have t=
o
> either drop out of order messages or buffer them. Yes, this is
> somewhat irritating, but as you demonstrate below, it's inherent
> in the design of post-handshake messages even if each side is
> only allowed to initiate one transaction at a time.
>=20
> It might be useful to explain this in the text, but I don't think
> anything else is needed..
>=20
> -Ekr
>=20
> On Wed, Mar 4, 2020 at 11:00 PM Hanno Becker <Hanno.Becker@arm.com> wr=
ote:
> > Thanks Martin for your thoughts.
> >=20
> > > It's unavoidable in any case. If you generate your own post-handsh=
ake message and
> > > then have to respond to post-handshake authentication, there will =
be two concurrent
> > > exchanges.=20
> >=20
> > Yes that's an instance of the second question b) which the post didn=
't further go into.
> >=20
> > I'm not yet convinced that this situation unavoidably creates the ne=
ed for duplicating state machines, though, and think that if possible we=
 should avoid it for the sake of implementation simplicity.
> >=20
> > Moreover, even if it is acceptable that state machines should be dup=
licated, it isn't clear (to me) how to logically separate them because t=
hey're all tied together by the use of the same global handshake sequenc=
e number. This creates non-trivial ambiguities like the following:
> >=20
> > Imagine after the handshake the server requests post-handshake authe=
ntication while, simultaneously, the client initiates a key update. When=
 the server receives the KeyUpdate, it assumes from the handshake sequen=
ce 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 le=
ad to failure of the connection, while here, we'd need the server to dro=
p the message or notice that it should fork a new state machine.=20
> >=20
> > Note that this problem already exists, albeit in less prominent form=
, in DTLS 1.2, where both sides may simultaneously trigger a renegotiati=
on.
> >=20
> > Thinking about it, it seems that the way to make this work is to seg=
regate the part of the retransmission state machine which establishes in=
-order delivery via handshake sequence numbers, and to have the duplicat=
ed contexts one level higher. When a handshake message comes in, it woul=
d be trial-fed into all existing contexts, either until one of them acce=
pts it after checking type and content, or potentially leading to the fo=
rking of a new context.
> >=20
> > However, this asynchronous nature of handling multiple post-handshak=
e messages is in conflict with the serialized nature of the handshake tr=
anscript used e.g. in the CertificateVerify message:
> >=20
> > Imagine a post-handshake client authentication to happen interwoven =
with another post-handshake message from client to server. When the clie=
nt writes the CertificateVerify, that would require the transcript of th=
e 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 ser=
ver receives a CertificateVerify message with a transcript it cannot val=
idate because it hasn't yet received all other authentication-independen=
t post-handshake messages that went into the transcript.
> >=20
> > Maybe I'm overcomplicating things, but as it stands it seems to me t=
hat the above are serious issues to be further discussed and clarified e=
ven if we accept state machine duplication.
> >=20
> > Happy to hear your thoughts.
> >=20
> > Cheers,
> > Hanno
> > *From:* TLS <tls-bounces@ietf.org> on behalf of Martin Thomson <mt@l=
owentropy.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=
=20
> > Option A please. Multiple state machines.
> >=20
> >  It's unavoidable in any case. If you generate your own post-handsha=
ke message and then have to respond to post-handshake authentication, th=
ere 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, =E2=88=9E), we might as well deal =
with the full implications of that.
> >=20
> >  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.
> >=20
> >  On Thu, Mar 5, 2020, at 01:19, Hanno Becker wrote:
> >  > Hi,
> >  >=20
> >  > [TL;DR]
> >  > The DTLS 1.3 spec (draft 34) doesn't fully describe the retransmi=
ssion state=20
> >  > machine in the case of post-handshake messages, which requires cl=
arification.
> >  > For example, is it allowed to send multiple post-handshake messag=
es without=20
> >  > waiting for ACKs for the previous ones? If so, how is the retrans=
mission=20
> >  > 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=20
> >  > answer, and so this post is mostly a request for discussion, hope=
fully=20
> >  > resulting in some common understanding and clarification of the s=
pec.
> >  >=20
> >  > Details:
> >  >=20
> >  > The following cases need addressing:
> >  > a) Is it allowed to send multiple post-handshake messages (e.g.,=20=

> >  > multiple session
> >  > tickets) without waiting for ACKs for the previous ones? If so, h=
ow is=20
> >  > the
> >  > retransmission state machine modeled for sender and receiver in t=
his=20
> >  > case?
> >  > b) How should simultaneous sending/receiving of post-handshake me=
ssages=20
> >  > be handled?
> >  > The current retransmission state machine doesn't allow sending an=
d=20
> >  > receiving
> >  > at the same time.
> >  >=20
> >  > Some thoughts on a) first:=20
> >  >=20
> >  > The spec mentions that post-handshake messages are treated as=20
> >  > single-message flights.=20
> >  > As such, the sender would enter WAITING state after sending the=20=

> >  > post-handshake message,=20
> >  > and move to FINISHED on receipt of the corresponding ACK. This,=20=

> >  > however, forbids sending=20
> >  > another post-handshake message in between, since sending isn't al=
lowed=20
> >  > in WAITING state.
> >  >=20
> >  > Option A: Fork state machine
> >  >=20
> >  > One could circumvent this by 'forking' the retransmission state m=
achine=20
> >  > for post-handshake
> >  > messages, i.e. declaring their semantics as if there were multipl=
e=20
> >  > independent state machines=20
> >  > for each outstanding post-handshake message. This essentially deg=
rades=20
> >  > the DTLS' ACK scheme
> >  > to a per-message acknowledgement.=20
> >  >=20
> >  > I believe that such an approach is not in the spirit of the rest =
of the=20
> >  > protocol and moreover=20
> >  > significantly increases complexity and thereby comes at the dange=
r of=20
> >  > slower adoption and/or bugs.=20
> >  > Moreover, it will significantly harden efforts for formal verific=
ation,=20
> >  > which should be considered
> >  > in light of previous efforts on TLS 1.3.
> >  >=20
> >  > Option B: Don't allow multiple post-handshake messages
> >  >=20
> >  > Forcing implementations to await an ACK before sending the next=20=

> >  > post-handshake message is a theoretical=20
> >  > option which would allow to stick to the existing state machine.=20=

> >  > However, this significantly increases=20
> >  > the latency of, say, the delivery of multiple session tickets, wh=
ich is=20
> >  > a valid use case. This is therefore=20
> >  > not a convincing option, either.
> >  >=20
> >  > Option C: Merge consecutive post-handshake messages into a single=
 flight.
> >  >=20
> >  > Another approach would be to treat multiple post-handshake messag=
es as=20
> >  > a single flight on the sender.
> >  > That is, when the sender is in state WAITING after sending the fi=
rst=20
> >  > post-handshake message, and the
> >  > user request to send another one, it moves into SENDING and then =
back=20
> >  > into WAITING as usual, appending
> >  > the new post-handshake message to the (so-far single-message) fli=
ght.
> >  >=20
> >  > How would that be handled on the receiver side?=20
> >  >=20
> >  > That's not entirely clear because a basic property of the TLS han=
dshake=20
> >  > that DTLS leverages now no longer
> >  > holds: Namely, that both sides implicitly know and agree on the b=
ounds=20
> >  > of flights. Here, multiple post-
> >  > handshake messages would be treated as a single flight on the sen=
der,=20
> >  > but the receiver doesn't know
> >  > when the flight is over. How should this be handled?
> >  >=20
> >  > This is to be explored further. One way to address this would be =
the following:
> >  >=20
> >  > Option D: Add an 'end-of-flight' signal to handshake messages to =
allow=20
> >  > dynamic-length flights.
> >  >=20
> >  > Recall that the handshake logic must inform the retransmission st=
ate=20
> >  > machine about when a flight=20
> >  > is over in the main handshake, allowing the state machine to tran=
sition=20
> >  > accordingly. This signal,=20
> >  > however, isn't explicitly conveyed to the receiver, because the=20=

> >  > receiver can figure it out for=20
> >  > himself.
> >  >=20
> >  > As mentioned, this isn't true anymore for batched post-handshake =
messages.
> >  >=20
> >  > One simple way to deal with is to add an explicit 'end-of-flight'=
 bit=20
> >  > in the handshake header
> >  > which informs the receiver about when a flight is over, in those=20=

> >  > situations where it's not
> >  > clear from the context.
> >  >=20
> >  > This would allow to keep a single retransmission state-machine as=
-is=20
> >  > while allowing for
> >  > batched post-handshake messages such as multiple session tickets.=
=20
> >  > Moreover, such a signal=20
> >  > would be trivial to implement because it's already implicit in th=
e main=20
> >  > handshake.=20
> >  >=20
> >  > For the wire-format, we can discuss different options, but that's=
 an=20
> >  > orthogonal question=20
> >  > to the issue of finding the correct conceptual approach.
> >  >=20
> >  >=20
> >  >=20
> >  > Happy to hear everyone's thoughts. It would be great if we could =
come=20
> >  > up with some
> >  > precise description of the state machine evolution for post-hands=
hake=20
> >  > messages that=20
> >  > is both simple and supports batched post-handshake messages.
> >  >=20
> >  > Best,
> >  > Hanno
> >  > IMPORTANT NOTICE: The contents of this email and any attachments =
are=20
> >  > confidential and may also be privileged. If you are not the inten=
ded=20
> >  > recipient, please notify the sender immediately and do not disclo=
se the=20
> >  > contents to any other person, use it for any purpose, or store or=
 copy=20
> >  > the information in any medium. Thank you.=20
> >  > _______________________________________________
> >  > TLS mailing list
> >  > TLS@ietf.org
> >  > https://www.ietf..org/mailman/listinfo/tls <https://www.ietf.org/=
mailman/listinfo/tls>
> >  >
> >=20
> >  _______________________________________________
> >  TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >  IMPORTANT NOTICE: The contents of this email and any attachments ar=
e confidential and may also be privileged. If you are not the intended r=
ecipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy th=
e information in any medium. Thank you.=20
> >  _______________________________________________
> >  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
>