Re: Unrecoverable loss pattern

Mikkel Fahnøe Jørgensen <> Thu, 01 March 2018 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C6E512F299 for <>; Thu, 1 Mar 2018 11:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Status: No, score=-2.697 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 qCvOAGh99yxu for <>; Thu, 1 Mar 2018 11:30:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D45C912F27D for <>; Thu, 1 Mar 2018 11:30:35 -0800 (PST)
Received: by with SMTP id u5so9208602itc.1 for <>; Thu, 01 Mar 2018 11:30:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=IRv4ZF6pT4P4MZEozK8P7QdL5zfQ65n4LXMyy2qDrCI=; b=Lr3liLSjsZkaykyqJhueKW0h4hs2U1jQkAT9ue8uUCxi6libdjqUPv8dazTCfR+z7F v/So4vO4K+lGN1qnmArMAQIKlmhpZ9q1TUu1d9hxCSMwPGYwUzI0sD02R8XOxZVQjddK dCOI6t4C/yGbwV1PG5Yvqn7wqR1aMqFNV4N5AT3t21QheT3PHsvOd+ZdD5WUeUECn61e RyR8ZlG2vIisCqG3bzYsbDjtHZ9u/oZtZfPVOvxWW/C30/7mQrwIHN8AmH9jPWcEj5c2 4Y+uj958x1CC7V2lo0ItgWiNni8Izzw1xAyVWQm6sNGGeiFwe/tAyNeLb504ojRnm4RR 570A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=IRv4ZF6pT4P4MZEozK8P7QdL5zfQ65n4LXMyy2qDrCI=; b=j7ROEu+lOB5B9UVm80qP/OXaBdlm6oyJctdB4WbRzgKpws1us+wmSkZiUacxCOXWMm 7SmSYQKQ6bHMcKl2+mJcS2w0BqG+IWqUxmpBF0b5mhkfoNkyUugGrpiQUtMLqg0AuAsi BRTaUVZpymEmo6zlBYbeHDA5bMnD5EJFatlTAE30ltumeG6f9i/d0xA/K28dHerT0QyC KJam7FCu9rrh1+t6cZ8THBIB7n0WuS8CfKIpyEz7yQNaTQGfW/etuQAN0bDRcDuN8qAf Bo47CM2h4xhGCzyksg91kO00glZ6MTTmUieTF6KZMyvJJHyszv47EH4fxZsdZ5Lp4zLm 8Gog==
X-Gm-Message-State: APf1xPBqBqteDunPPqK2N4DMlBqUv5/mVsoQd7FyEglULCItwTgb5vFJ i1gbXTX/HO4TrsMArQOtzpwdP7RBAciLDWcN9PE=
X-Google-Smtp-Source: AG47ELs3VNAHbTDDJzqgJQNvHb8mXA//+Ll3KnftU6Xp72SHi6LBWaI53QJ0SFeo/DDE3PgwP3zruGP9vGK3S1cpuck=
X-Received: by with SMTP id b128mr3986467itc.80.1519932635134; Thu, 01 Mar 2018 11:30:35 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 1 Mar 2018 14:30:34 -0500
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 1 Mar 2018 14:30:34 -0500
Message-ID: <>
Subject: Re: Unrecoverable loss pattern
To: Ian Swett <>, Christian Huitema <>
Cc: IETF QUIC WG <>, Martin Thomson <>, Marten Seemann <>
Content-Type: multipart/alternative; boundary="001a11405c76ccbefb05665ee49a"
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: Thu, 01 Mar 2018 19:30:38 -0000

I sort of like the idea of closing stream 0 after unencrypted data. For
that matter, a stream could be burned on every key or path migration which
could act as a handoff signal. But it is more a path thing than a stream
thing because ACK timings depend on path and encryption state. I’d like to
view the handshake as a separate path from the encrypted content - also
because the initial connection ID might be something arbitrarily different
from the later connection.

Receipt of encrypted data is not necessarily sufficient because a server
might start to optimistically transmit data soon after the initial packet
in anticipation of the client accepting its handshake. But the server has
not established full trust at this point, so consequently the client could
not use it as an implicit ACK, at least not unless the Client Finished
message becomes irrelevant.

I think Finished was needed in part because it is a TLS thing that is
unwise to mess with, and in part because a Client Auth cert could be long,
but I am really not sure about this. At least there appears to be cases
where the encryption cannot be trusted before the Finished is received.

On 1 March 2018 at 20.13.32, Ian Swett (

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 <>

> 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