Re: Unrecoverable loss pattern

Christian Huitema <huitema@huitema.net> Fri, 02 March 2018 00:58 UTC

Return-Path: <huitema@huitema.net>
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 AF386126C2F for <quic@ietfa.amsl.com>; Thu, 1 Mar 2018 16:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 H6Zd7I2juU_j for <quic@ietfa.amsl.com>; Thu, 1 Mar 2018 16:58:48 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C12C127698 for <quic@ietf.org>; Thu, 1 Mar 2018 16:58:45 -0800 (PST)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1erZ23-0006El-7H for quic@ietf.org; Fri, 02 Mar 2018 01:58:43 +0100
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1erZ1x-0002LV-Qs for quic@ietf.org; Thu, 01 Mar 2018 19:58:41 -0500
Received: (qmail 1107 invoked from network); 2 Mar 2018 00:58:36 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.241]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martenseemann@gmail.com>; 2 Mar 2018 00:58:35 -0000
To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= <mikkelfj@gmail.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Marten Seemann <martenseemann@gmail.com>
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <c030fc96-0ce6-bc80-b9b3-4f3bd9df305f@huitema.net>
Date: Thu, 1 Mar 2018 16:58:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAN1APdcrzJ+q5SnVAFF8xEjstG5OfejrcLe-vb5c2-aHKkPFAQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------86B3CC34DDA9E42968486789"
Content-Language: en-US
Subject: Re: Unrecoverable loss pattern
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5g8nwLKZm3tP4iEMKHMN0y1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViqnc/rdGrr4e/v2BeunMoKc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYYaL692xZ+s/JxHzsGpky notaRL+WFHXyFxym27tA2WWpe+zzbXrsktsSZNCkA6NdV7ocmmylx8nwrDTeRmvwzwfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4DS S1KvBBuuCTqN/Awcg3iqSGG/BQd7r2NVEaNhWos5ptYctv/t1V4ZJYN4UHlmvCsccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtqfKCfNjMFBwHxjV+D9DD/qBi6owqeb+h1kbxIVWYdC7GPG0 gBeFe8dTkoKHsNX/zVeqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i155AiyoKXYtKB9hGDzG5Ak-vsk>
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: Fri, 02 Mar 2018 00:58:50 -0000

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?

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