Re: Unrecoverable loss pattern

Ian Swett <> Mon, 05 March 2018 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCAD1124B18 for <>; Mon, 5 Mar 2018 12:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 74lDzdsTnsZy for <>; Mon, 5 Mar 2018 12:08:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0B2B12E8E4 for <>; Mon, 5 Mar 2018 12:08:55 -0800 (PST)
Received: by with SMTP id p78so19369319iod.13 for <>; Mon, 05 Mar 2018 12:08:55 -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=EgONXaZD74RPPgKY8kiFC0LZipwkc60yv4sNvyaynwo=; b=WLYF86kVGn2I0OeN+4d/s/MLhoaqIdo0KPfEPYBKJIhJEDViIrgvW8eBVJf6bXX6H5 y3q10mtTD7K6VMA+X9UTns/HjZE/Yaeb7eekyul6EZl6KqwpKfiu//X5+06coJyH5T3A c+f6jPzvXCaTrkIWB0z0sKeXHvR+cR+nbCliZZl9ZV9Srn1G9xt3HB7rk931bZssh9Jt 8ymepmegI0oxxBH6bcX5jqkiFA07oL+7iqOysFu4pU9d/r1p+ZI0o+iL6SzZw9VzEuzQ ZVVVMXL0M69h3X9Gr9o3T4vXU1e5wLLTcxw6DETIvxZ0UgHZMkpvnrthvMjRp/dUl8Dc OJzA==
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=EgONXaZD74RPPgKY8kiFC0LZipwkc60yv4sNvyaynwo=; b=ce0IsRISkvJLMXPP8nHRtdTauvqxOgTKq1oq+epj0d4oII+xC7Il1QzLWbNrYbR1rQ 8GnP4G0lODrDhQXifZsNDJwney4TjlX3bINfpKdujMHv/ItVh3sVMWFULSVFz3KTDSna 0lFZTY1mIAlHYLpKvnVqYW2Wv7FGi6tUMgbYM7o/deqDpQNG0SVvLKmaCczdDfJoBl85 KYqg1mxNwFUZNofmj6dKPbYx7ssndMwVdXjgw2kJAX4EQW8XegTSaejL60f6jQVBENl8 M5NNdDDK9RS9hvK77aoL+GvgG1OXuEIw5ECpV9qetFJigTFVrgLESNlwm3HqRBI1HQqY +q7g==
X-Gm-Message-State: APf1xPA/WhsAHmB6/W3lzIVWJqYjU/hX0L+Boc2jLtF08WxZ5TZ/c92H TdtIeHVj8hHbEp7ttkhvb3ed174+H1FYsWO9DH0+dA==
X-Google-Smtp-Source: AG47ELulJExMq9YyBofe1LyZ0BjJJzFbODUOzK0CxKjK6GDU+7A9nWduUhn+gaS5cr4ynvUVx7z7CYlHLhle1/1JVv0=
X-Received: by with SMTP id f79mr18589378iod.102.1520280534863; Mon, 05 Mar 2018 12:08:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Mon, 05 Mar 2018 20:08:43 +0000
Message-ID: <>
Subject: Re: Unrecoverable loss pattern
To: Christian Huitema <>
Cc: Mikkel Fahnøe Jørgensen <>,, Marten Seemann <>, IETF QUIC WG <>, Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a113fb9263e0bf10566afe5a7"
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, 05 Mar 2018 20:09:00 -0000

On Thu, Mar 1, 2018 at 7:58 PM Christian Huitema <>

> On 3/1/2018 11:30 AM, Mikkel Fahnøe Jørgensen wrote:
> 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.
> If you do that, what do you use for post handshake TLS messages, such as
> new session ticket messages?
I was thinking that you'd designate a different stream as the
post-handshake encrypted crypto stream and stream 0 would become the
unencrypted crypto stream.  Possibly that stream would be subject to flow
control, and we could not subject stream 0 to flow control, which may be
simpler than the current flow control arrangement?  Or possibly that causes
more problems than it solves, since TLS is designed as a single stream.

> 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.
> Yes.
> -- Christian Huitema