Re: Unrecoverable loss pattern

Ian Swett <ianswett@google.com> Mon, 05 March 2018 20:08 UTC

Return-Path: <ianswett@google.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 DCAD1124B18 for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 12:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 74lDzdsTnsZy for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 12:08:58 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 D0B2B12E8E4 for <quic@ietf.org>; Mon, 5 Mar 2018 12:08:55 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id p78so19369319iod.13 for <quic@ietf.org>; Mon, 05 Mar 2018 12:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.107.131.82 with SMTP id f79mr18589378iod.102.1520280534863; Mon, 05 Mar 2018 12:08:54 -0800 (PST)
MIME-Version: 1.0
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> <CAN1APdcrzJ+q5SnVAFF8xEjstG5OfejrcLe-vb5c2-aHKkPFAQ@mail.gmail.com> <c030fc96-0ce6-bc80-b9b3-4f3bd9df305f@huitema.net>
In-Reply-To: <c030fc96-0ce6-bc80-b9b3-4f3bd9df305f@huitema.net>
From: Ian Swett <ianswett@google.com>
Date: Mon, 05 Mar 2018 20:08:43 +0000
Message-ID: <CAKcm_gOYvToz_PuXN6+g4VZ-iHVf1pT=_LpQi-h-6wab7QN92A@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Christian Huitema <huitema@huitema.net>
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>, ianswett=40google.com@dmarc.ietf.org, Marten Seemann <martenseemann@gmail.com>, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a113fb9263e0bf10566afe5a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OtRYkg1rV_r9d8OwkBcRi1kH3EI>
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, 05 Mar 2018 20:09:00 -0000

On Thu, Mar 1, 2018 at 7:58 PM Christian Huitema <huitema@huitema.net>;
wrote:

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