Re: Unrecoverable loss pattern

[Martin Thomson <[e-mail]>]

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.

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.




On Mon, Feb 26, 2018 at 6:28 PM, Christian Huitema <[e-mail]> wrote:
> On 2/25/2018 6:07 PM, Martin Thomson wrote:
>
>> Yes, this is a real issue.  It arises because the packet that would
>> normally trigger loss detection for the request packet (the ACK for
>> the Finished) never gets sent because the server believes the client
>> to be quiescent.  The server believes that because it discards the
>> cleartext packets that it receives.
> We debated that with issue #1018
> (https://github.com/quicwg/base-drafts/issues/1018). At the time, we saw
> two options:
>
> 1) Allow the "finished" message to be transmitted in 1-RTT protected
> packets. This was nixed because it seems to interfere with the formal
> proofs of TLS 1.3.
>
> 2) Allow the server to accept retransmission of handshake packets
> intermixed with 1-RTT protected packet. Clearly, this open a DOS attack,
> as third parties can now inject such packets, consume packet numbers,
> and possibly cause good data to be dropped.
>
> I was not aware that the spec pushed a third alternative, to mandate
> that the server to just drop handshake packets after receiving the first
> copy of the finished message. As Marten says, that puts the client in a
> bad position if the first ACK is lost and the server is silent after that.
>
> The solution might be to send a "Finished received" frame in the
> protected data flow, and require an ACK for that frame. That way, the
> problem would really be solved.
>
> -- Christian Huitema
>
>
>
>
>
>
>
>