Re: Unrecoverable loss pattern

[Christian Huitema <[e-mail]>]

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