Re: Unrecoverable loss pattern

Martin Thomson <martin.thomson@gmail.com> Mon, 26 February 2018 08:51 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 2B26712D777 for <quic@ietfa.amsl.com>; Mon, 26 Feb 2018 00:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 JLOEA5v_6FSf for <quic@ietfa.amsl.com>; Mon, 26 Feb 2018 00:51:38 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 893CE1273B1 for <quic@ietf.org>; Mon, 26 Feb 2018 00:51:38 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id n74so12490863ota.1 for <quic@ietf.org>; Mon, 26 Feb 2018 00:51:38 -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=ZHGiY/waMgn0THSDhZiE6hWNRwrrEBpaZqmFHefppuk=; b=SLoJFYM2VaPOGiWkbeN4ytn5XpOY2lLGsAzTsZG46OK0PpxMaZRqcSGPzkS61/QwbP hxY9q4U/KQXsaEu0/0KzFdDh8PE0nn8d3ZJ03n8hwV3J2bdhnGzFKZ2nTmmD5P48XFm9 aUbp17WCBvPxYcp7RFdBLjgNp0TXKGZ3iCf7D0JcE9M3nj6RJbV4Kf7hkbOAVwFgOahr GiFsPb28phH0Y2JsffEYaVbjaxjjDlUA63TKnm3UDtq2HMpFLWuAI8GectZ4LsILwGei Sme152dZDExmCGIfa0v0KR0Lit/4ptOfqsFHAbTvGR5QkYiYqNH+OEsWF6dsNRPuRdrz MTNw==
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=ZHGiY/waMgn0THSDhZiE6hWNRwrrEBpaZqmFHefppuk=; b=dmR21wr5RhWz2BfnL1Kv0VTUCM3j4nlIyj/uxJ7P//Y9Hi0JLSfQOQFRFbJM1DMwg4 kfC2/7vDh/XbQNTFe2cNvPMlB/LCNiEoo7IGQlkCaKseGXMwWDVqOBZG2fYt5ZIcT8W9 RWCIYQDbc7pK16sPFd1RDGk3PF2G6MLLaxDtejW3TVYIc3KjnlN2+yabMwAM/ZE+kkwh vRi7XG7LS3bwXAwGPbFOCcPrIlwWkh8cgD6d1jZzdzcSTiES19QDk2HvcYnMo2YOL/hK uYU8s7HTVf6gHP2CJlp9cL1jCWWsEDey6tzAjHB3FBjCcz5YNKpO9WtA7/+SAFF1+Wd3 bwdQ==
X-Gm-Message-State: APf1xPDpu8T5iqP61GU/vudt5Cno9WKeMKsmS2dGIP3r50Dv2w1WsWd3 H9jHVt+qjCQR6lAihfHAUy1f3ZHUx/3k0El8U7Y=
X-Google-Smtp-Source: AG47ELuLwBdqVlgYdmfVeukYYpw3KAxwk9ar+u29Lt/LwIvwhBkBPj9UeDhgogNFZtU7Xlv8dufhH/zXJHTDxGnt91k=
X-Received: by 10.157.73.3 with SMTP id e3mr7407901otf.15.1519635097779; Mon, 26 Feb 2018 00:51:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Mon, 26 Feb 2018 00:51:37 -0800 (PST)
In-Reply-To: <f62726b4-564a-4e45-726b-63705753ddf2@huitema.net>
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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 26 Feb 2018 19:51:37 +1100
Message-ID: <CABkgnnU78mE55N9KHx2FqR6AvthyM86-+zG-VknQ3tfpeKh=Gw@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Christian Huitema <huitema@huitema.net>
Cc: Marten Seemann <martenseemann@gmail.com>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/byvMYEnOLLpFQIxS9BKC8Ybsutw>
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: Mon, 26 Feb 2018 08:51:41 -0000

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 <huitema@huitema.net>; 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
>
>
>
>
>
>
>
>