Re: Unrecoverable loss pattern

Marten Seemann <> Mon, 26 February 2018 01:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83719127275 for <>; Sun, 25 Feb 2018 17:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fak7t_x5aqRM for <>; Sun, 25 Feb 2018 17:31:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C9051271FD for <>; Sun, 25 Feb 2018 17:31:03 -0800 (PST)
Received: by with SMTP id k187so8830809vke.12 for <>; Sun, 25 Feb 2018 17:31:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HL3XhoyVHJ/eTKRAqXBsF2yCh+sEifHNIkFMGgjYU6g=; b=EFoiHFVJNLf1fljBnGEEymI/vkZpyM8AiRS0B8mgGPFxzhMi6vvzaYqXBujg431g/S y8oMoUP23dRGNFVLvKhx987qbG2gLnG1DWRwk8BllobLOhvnW71dhx9rKs1Bhyb6KhiG iqY+eMuVtQ3iq/8mlvDEXeTYRnrLRVu+89OBdaCpISY9PBNg9gwr3/G3W4Yjb0Zlrcp0 F/0BeFCoEwfkjLDS2tk/n518jyS+VFM/qN/Q/sLjgfVELL2Z6khkCj0jad5MSIlJt19t 1npQHrlm+lQsT7MW5X62Z6q+cG0tzuZaZZokYEkl200qqrjC30Ox/WNC2hs/V008nEr8 LZMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HL3XhoyVHJ/eTKRAqXBsF2yCh+sEifHNIkFMGgjYU6g=; b=eVVQlBlcz8U9W9QkWzcgAm2SqgFuWh4vg3vZJOoMmYgdK+yvOp4ya/9R+IrZVQciB+ zYsQAPZg18FY49wdqmOm1SCLUtaODapCHU9B+mHamn//LGO0Y+N3aWZsHmjly6xlhisg Ql5bdjynQnRM9zV+mU+siNZm71vFAO52FtleDbTtyrhiFZ+yFcJ1Q3Nx8l+QIrwWooVJ T7jbSbwQVgsXhhGTFTxwFfc9YsQuGAPDSKN3hF3slWi7WIMpER8+t28YnLSwYXQAVXNh F0Ums5UBP9rdS+q+jQcFNYiPtGqBhnJwepIL/vuN4xt9cx83nHR83H1TYXiNgk9Q7NGQ BZCw==
X-Gm-Message-State: APf1xPAdRL50wgDqf8n51Eg0pp2Pk9CeZ8zrTpK1pb7JSSRXmYrYgQ9c wNmvWdnfH6OO/zvkiOYRVlV/I5ivcpZn1cdXRtQ=
X-Google-Smtp-Source: AG47ELu5cAFcLDtL+acghDZBf1imwSy9Cxogdzja/I2474PPD9x0VPD3DFxfq0v1szxjHRrnfC69hmyWCc3EzJDFKyg=
X-Received: by with SMTP id o62mr6427vkg.152.1519608661985; Sun, 25 Feb 2018 17:31:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Marten Seemann <>
Date: Mon, 26 Feb 2018 01:30:51 +0000
Message-ID: <>
Subject: Re: Unrecoverable loss pattern
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="94eb2c07d90a7ecee405661376f1"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Feb 2018 01:31:05 -0000

The problem is that the server will not open the unencrypted packet
containing the retransmission of the FINISHED, since it already completed
the handshake AND received ACKs for all its handshake packets. We *could*
fix this problem by making the server accept unencrypted packets
indefinitely, but this comes with a whole range of problems of
man-on-the-side attacks.

On Mon, Feb 26, 2018 at 9:20 AM Christian Huitema <>

> On 2/25/2018 4:58 PM, Marten Seemann wrote:
> @Nick: The server did get all handshake packets, please see 1. in my
> description. It's the server's ACK for the FINISHED message that is lost,
> not the FINISHED message itself.
> @Martin: Yes, it is, but I don't think there's anything problematic about
> the language in this paragraph. Since the server received ACKs for all the
> handshake messages it sent, it makes sense to not open unencrypted packets
> any more.
> See and
> for  discussion of
> related issues.
> Picoquic manages these issues by handling "ACK of ACK". Normally, it will
> send ACK frames that acknowledge all packets received so far, potentially
> with a long list of ACK ranges. So if an ACK is lost, the next ACK will
> repeat the information that it carried. The list is only pruned when an
> "ACK of ACK" is received.
> In your example, if the FINISHED message is not acknowledged, the client
> will retransmit the stream zero data containing the FINISHED message in a
> new Handshake packet. The server will have to send an ACK of that packet,
> and the ACK range will also cover the previous packet. There is no problem
> for sending that ACK. You cannot acknowledge a protected packet in a clear
> text message, but nothing prevents you from acknowledging clear text
> packets in protected messages.
> -- Christian Huitema