Re: Unrecoverable loss pattern

Martin Thomson <martin.thomson@gmail.com> Thu, 01 March 2018 22:47 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78044126CF9 for <quic@ietfa.amsl.com>; Thu, 1 Mar 2018 14:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2374vNE2BSog for <quic@ietfa.amsl.com>; Thu, 1 Mar 2018 14:47:17 -0800 (PST)
Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B34D126CD6 for <quic@ietf.org>; Thu, 1 Mar 2018 14:47:17 -0800 (PST)
Received: by mail-ot0-x236.google.com with SMTP id n74so7154377ota.1 for <quic@ietf.org>; Thu, 01 Mar 2018 14:47:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uWANXf5PUYNUnmQUThIjWyC0AtdJDpEUYGU+eET/tPM=; b=XLqxhz5ETh3nUpXPaDWJaOxvqfFbKT9QvtEKVyi7j6XrIZU4ngwrjUD4hr9WhQeMQl gSdP7hhDozeBlA/V5frbN8yqYTAcgElDg786rZjXW/2zBWM1a7OXOV2vREAtmc7EzqC9 851douOYXdZvrjBKZoWubFKcVaDybSu6jCYBYITNBNorGeezQrMredFqFVrYU9Ymf4As D/57Hn6iB1k/koNM89vyj5drMyltnEWdy83bSRUn4h9OC/+wUwe6pxHPMx0Gx1CCSzd+ dwfle6V2UPgfYLCbWNfCQkswN9/X6+1XSw77HuwdlSXNJpxbMZ48aCl+AFfKOYjstb+X BFpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uWANXf5PUYNUnmQUThIjWyC0AtdJDpEUYGU+eET/tPM=; b=j7fxrOnSsTD89G7DtWwcEHtQr8GSJODAXtWmPcAsBCo0Zgll9KQcxGcjwcyMak0YOX 6VwQGRLmbXW/Csk02/lB6PjziiWvGR5zsWphIb2mpw+jdWct0wva9OSHUsmPnxFnaADZ IdX/HhvfSaZfvOgeiMe7QFM7gtIrOsuUuQ5XN+4kjeRj1rZS3FvUMu/HgBYs4fowiFgT J9YT+wOT9ve4lZc4r4LYfqBx6SPRAzhMWj2O++j8LQfuiBWCdPcL/U+PNnwsXVdT72qq xL+zNwdjKXN1qXzkZRBWtQxJVQizQHP23S/aUQIDSzLSGAWpI09FQDfmp67Q3u25lil+ yZag==
X-Gm-Message-State: APf1xPDsQHJDGoW9AIst5z0JwE1a0822Gs40XYUp+k065QpLUAw765+l y+U0z6TjYa9D71LiQLokimVZsh4CpwPOwDHsNsk=
X-Google-Smtp-Source: AG47ELuDS4cboVAVHgXjQdmLN/mFT6qAsuGhXAVAu3XTuDpBHWyf68BGnHejWQhGz1jN1ik+Sd8ozu1E5BiTBAhhH0E=
X-Received: by 10.157.64.181 with SMTP id n50mr2693836ote.241.1519944436741; Thu, 01 Mar 2018 14:47:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Thu, 1 Mar 2018 14:47:16 -0800 (PST)
In-Reply-To: <CAKcm_gPk4e4JvOqm52VDKaMsvy9G0Fx5BHfwQawrxmpZkyo+pw@mail.gmail.com>
References: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com> <CABkgnnWuXJb2_BcfU4N=ODwy5JDZKBBd6TyhFmXLbPgVrvCoEA@mail.gmail.com> <CAOYVs2q0q6YrFfipd7UEENoz2ht2Mr0fPqnvy5pJRz-bPxCJpw@mail.gmail.com> <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> <CAOYVs2ogy77tjE+e9_mj6YNYcsDP0iduUKsE-_JnMrOeo4jVbQ@mail.gmail.com> <CABkgnnVLdKiaEDdGKjLXB9wNZ8vxvV_ZyJQnLAR4VxsjUDvjyg@mail.gmail.com> <f62726b4-564a-4e45-726b-63705753ddf2@huitema.net> <CABkgnnU78mE55N9KHx2FqR6AvthyM86-+zG-VknQ3tfpeKh=Gw@mail.gmail.com> <9d646ca7-2c95-62fd-206f-10ec6ce4cd5d@huitema.net> <CAKcm_gOb_ZYD3bWZVq5y0O50jwnh98xME7p_tgY-TCNSZRkGfg@mail.gmail.com> <CABkgnnWF3ib_ccQHLv2W++HW9QJdnT=YEbGo=va39MDJq-9Z9Q@mail.gmail.com> <CAKcm_gPk4e4JvOqm52VDKaMsvy9G0Fx5BHfwQawrxmpZkyo+pw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 2 Mar 2018 09:47:16 +1100
Message-ID: <CABkgnnW=GLh1D_w2HTC3D6ioS+WaoyCxuuH5OyQmL3oAr3g6Mg@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Ian Swett <ianswett@google.com>
Cc: Christian Huitema <huitema@huitema.net>, Marten Seemann <martenseemann@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/h4vWUNrvWoUbDPa6EwOMRwJ7Os4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2018 22:47:19 -0000

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 <ianswett@google.com>; wrote:
> 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 <martin.thomson@gmail.com>;
> wrote:
>>
>> 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 <ianswett@google.com>; wrote:
>> > 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 <huitema@huitema.net>;
>> > 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
>> >>
>> >