Subject: Re: Unrecoverable loss pattern

From: Ian Swett <[email-masked]>
Date: Thu, 01 Mar 2018 19:13:12 +0000

I'm a bit confused about which case we're concerned by, so I'll try to talk
through my understanding.

Two timers won't solve the problem of the ack of the Finished being
lost(and then the acknowledgement never being sent again) that Marten was
discussing, because as Christian said, we won't process re-transmissions of
the Finished message because they're not encrypted and it will be stuck in
an undeliverable/unackable state.

The one byte frame could be an explicit signal to move on, but we still
need a way to stop re-transmitting the Finished.  Does that frame serve as
an acknowledgement of the Finished as well?  Doesn't the receipt of
encrypted packets also serve as an acknowledgement of the Finished?  In
either case, we're discussing an implicit ack of sorts.

One totally different(and possibly poor) alternative would be to only send
unencrypted handshake data on stream 0, and when you receive an encrypted
packet and your handshake has completed, if stream 0 isn't already closed,
reset it, since you'd know the handshake has completed.  We'd have to
allocate a different stream for post-handshake encrypted data, but that may
be a win anyway, since it would clearly define which streams were encrypted
and which weren't?

Related Q: At some point, weren't we discussing not sending finished?

On Mon, Feb 26, 2018 at 1:45 PM Christian Huitema <[email-masked]>
wrote:

>
>
> On 2/26/2018 12:51 AM, Martin Thomson wrote:
> > The issue in #1018 (as I understood it) was the fact that Finished
> > could be protected (and thereby authenticated), but it was not.  Not
> > having it protected makes it vulnerable to all sorts of attack.
> >
> > This is different, it's not an attack, it's just an unfortunate
> > interaction between the loss recovery algorithms and the TLS mapping.
>
> Actually, the issue was that allowing Finished to be repeated in clear
> text allows for a DOS attack on the server. The spec changed to ignore
> handshake packets after Finished is received once. That closes the DOS
> issue, but it opens the "ACK of Finished" issue.
>
> >
> > Other than running multiple timers as I suggested, you could also
> > force the server to respond to cleartext packets with a repeat of its
> > ACK.  It doesn't even have to look at what it received, it just plays
> > out the last ACK.  That's what we do in our DTLS 1.3 implementation.
> > It works.  The trick there is that once you have an ACK for the ACKs
> > that acknowledge the handshake you stop the special behaviour.
> >
> That was actually the first solution I thought off. That works too, but
> there are two downsides. First, you get a "twitch trigger" -- send an
> handshake packet, get the server to send an ACK. Not a very big deal,
> but slightly annoying. Second, it relies not only on implementing ACK of
> ACK, but also on triggering a special behavior for the ACK of the ACK of
> the last handshake packet. Many implementations do ACK of ACK
> management, but grafting a special case in that path is a bit tricky.
> That was my thought process before proposing a simple one byte
> "handshake complete" frame. The special frame is easier to integrate in
> the receive processing.
>
> -- Christian Huitema
>
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 1 Mar 2018 14:30:34 -0500

I sort of like the idea of closing stream 0 after unencrypted data. For
that matter, a stream could be burned on every key or path migration which
could act as a handoff signal. But it is more a path thing than a stream
thing because ACK timings depend on path and encryption state. I’d like to
view the handshake as a separate path from the encrypted content - also
because the initial connection ID might be something arbitrarily different
from the later connection.

Receipt of encrypted data is not necessarily sufficient because a server
might start to optimistically transmit data soon after the initial packet
in anticipation of the client accepting its handshake. But the server has
not established full trust at this point, so consequently the client could
not use it as an implicit ACK, at least not unless the Client Finished
message becomes irrelevant.

I think Finished was needed in part because it is a TLS thing that is
unwise to mess with, and in part because a Client Auth cert could be long,
but I am really not sure about this. At least there appears to be cases
where the encryption cannot be trusted before the Finished is received.

On 1 March 2018 at 20.13.32, Ian Swett (ianswett=[email-masked])
wrote:

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 1 Mar 2018 14:30:34 -0500

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Mar 2018 08:28:31 +1100

Two timers solves the problem because it leads to the request being
sent on TLP (or RTO), which unsticks the whole thing.  That is, if you
consider the problem to be less that the Finished isn't read, but more
that the handshake timers disable TLP/RTO.

On Fri, Mar 2, 2018 at 6:13 AM, Ian Swett <[email-masked]> wrote:
> Two timers won't solve the problem of the ack of the Finished being lost(and
> then the acknowledgement never being sent again) that Marten was discussing,
> because as Christian said, we won't process re-transmissions of the Finished
> message because they're not encrypted and it will be stuck in an
> undeliverable/unackable state.
>
> The one byte frame could be an explicit signal to move on, but we still need
> a way to stop re-transmitting the Finished.  Does that frame serve as an
> acknowledgement of the Finished as well?  Doesn't the receipt of encrypted
> packets also serve as an acknowledgement of the Finished?  In either case,
> we're discussing an implicit ack of sorts.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Mar 2018 08:30:02 +1100

> Related Q: At some point, weren't we discussing not sending finished?

This has come up a few times.  We'd start encrypting Finished before
we did that.

---

From: Ian Swett <[email-masked]>
Date: Thu, 01 Mar 2018 21:35:30 +0000

Sure, but then aren't you stuck with unackable data that never goes away.
That's just ughhh.

An easier solution than two timers(in my opinion) is to move out of
handshake mode into TLP/RTO mode as soon as you receive a forward secure
packet, since the goal of handshake mode is to ensure the information
necessary to derive keys is delivered before the things encrypted with
those keys.

On Thu, Mar 1, 2018 at 4:28 PM Martin Thomson <[email-masked]>
wrote:

> lost(and
> need

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Mar 2018 09:47:16 +1100

So rather than

if handshake packets outstanding

you would go to

if not 1-RTT keys available

That might work equally well.

I think that the Finished is still acknowledged, though the
interaction with your recommended algorithm for dropping
acknowledgments might not be good.  The server can ACK Finished from
the first flight, but it will drop that ACK when it sees the client
acknowledge its ACK of the request packet and then the client will
continue sending Finished forever.

On Fri, Mar 2, 2018 at 8:35 AM, Ian Swett <[email-masked]> wrote:
> necessary to derive keys is delivered before the things encrypted with those
> keys.
>
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Mar 2018 16:25:40 -0800

On 3/1/2018 11:13 AM, Ian Swett wrote:

> The one byte frame could be an explicit signal to move on, but we
> still need a way to stop re-transmitting the Finished.  Does that
> frame serve as an acknowledgement of the Finished as well?  Doesn't
> the receipt of encrypted packets also serve as an acknowledgement of
> the Finished?  In either case, we're discussing an implicit ack of sorts.

My idea was that it is only sent after receiving the Finished message.
"I have received the Finished Message, I am done with the handshake, you
can consider that all handshake packets are implicitly acknowledged."

Of course, there is a downside to that. Servers who are eager to start
sooner might send that *before* they receive the Finished message. But
then, they could also guess the packet number that will be used to send
the finished message and forge an ACK. Unless we are willing to make the
numbers jump at this point, or something like that.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Mar 2018 16:58:33 -0800

On 3/1/2018 11:30 AM, Mikkel Fahnøe Jørgensen wrote:

> I sort of like the idea of closing stream 0 after unencrypted data.
> For that matter, a stream could be burned on every key or path
> migration which could act as a handoff signal. But it is more a path
> thing than a stream thing because ACK timings depend on path and
> encryption state. I’d like to view the handshake as a separate path
> from the encrypted content - also because the initial connection ID
> might be something arbitrarily different from the later connection.

If you do that, what do you use for post handshake TLS messages, such as
new session ticket messages?

>
> Receipt of encrypted data is not necessarily sufficient because a
> server might start to optimistically transmit data soon after the
> initial packet in anticipation of the client accepting its handshake.
> But the server has not established full trust at this point, so
> consequently the client could not use it as an implicit ACK, at least
> not unless the Client Finished message becomes irrelevant.
>
> unwise to mess with, and in part because a Client Auth cert could be
> long, but I am really not sure about this. At least there appears to
> be cases where the encryption cannot be trusted before the Finished is
> received.
Yes.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Mar 2018 16:58:33 -0800

Yes.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Mar 2018 16:58:33 -0800

Yes.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 2 Mar 2018 02:10:49 -0500

On 2 March 2018 at 01.58.48, Christian Huitema ([email-masked]) wrote:

This isn’t fully thought out, but the idea is that each such exchange has a
logical conclusion and streams termination could communicate that.

Rekeying isn’t tied to paths for the time being, but there could be a one
to many relation between keys and paths such that each path has exactly one
set of key pairs.

There could be ambiguity in ordering, which is mostly an issue with
serialising against the TLS interface in case you deal with multi-path
rekeying, I suppose - since I haven’t worked closely with that yet.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 2 Mar 2018 02:10:49 -0500

---

From: Ian Swett <[email-masked]>
Date: Mon, 05 Mar 2018 20:08:43 +0000

> new session ticket messages?
I was thinking that you'd designate a different stream as the
post-handshake encrypted crypto stream and stream 0 would become the
unencrypted crypto stream.  Possibly that stream would be subject to flow
control, and we could not subject stream 0 to flow control, which may be
simpler than the current flow control arrangement?  Or possibly that causes
more problems than it solves, since TLS is designed as a single stream.

---

From: Ian Swett <[email-masked]>
Date: Mon, 05 Mar 2018 20:08:43 +0000

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 5 Mar 2018 12:30:31 -0800

Yes, I was having the same thought recently - that stream 0’s non-flow
control ought to end along with the stream itself. That naturally begs for
a different post handshake crypto stream, but in this case linearity is
guaranteed because you simply wait for stream 0 to end.

End of stream 0 thus signals handshake termination, and it avoids
accidentally processing a frame with the wrong crypto level.

In the more general case it is not so clearcut because you don’t want to
change streams when you change paths, even if there are some flow control
aspects that are appealing. But this can wait until multi-path becomes more
clear and also ties in with packet number visibility, to a degree.

On 5 March 2018 at 21.08.55, Ian Swett ([email-masked]) wrote:

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 5 Mar 2018 12:30:31 -0800