Re: Unrecoverable loss pattern

Christian Huitema <huitema@huitema.net> Mon, 26 February 2018 07:28 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 DDD95120721 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 23:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Tv6v43KPu-Rn for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 23:28:58 -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 0688F1201F2 for <quic@ietf.org>; Sun, 25 Feb 2018 23:28:58 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eqDDT-0003Zq-6A for quic@ietf.org; Mon, 26 Feb 2018 08:28:56 +0100
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eqDDM-0004Me-Ls for quic@ietf.org; Mon, 26 Feb 2018 02:28:53 -0500
Received: (qmail 9725 invoked from network); 26 Feb 2018 07:28:45 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 26 Feb 2018 07:28:45 -0000
To: Martin Thomson <martin.thomson@gmail.com>, Marten Seemann <martenseemann@gmail.com>
Cc: QUIC WG <quic@ietf.org>
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <f62726b4-564a-4e45-726b-63705753ddf2@huitema.net>
Date: Sun, 25 Feb 2018 23:28:43 -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: <CABkgnnVLdKiaEDdGKjLXB9wNZ8vxvV_ZyJQnLAR4VxsjUDvjyg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: Unrecoverable loss pattern
X-Originating-IP: 168.144.250.232
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.25)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5gJNvufdQwOoW5kBtSJ7JOB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVirkV7J0Wi+NzbTtnelSqDO87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X1MKVprlQYwN+KHznEQNFP2RJjTwYR9fdVd4GNOGh/gxw/SqpkOks8V3qTQf2nUD3wfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4Cp b4mi9wLRe0dO1qfOpsb8SGG/BQd7r2NVEaNhWos5pmr/mO1KyGAqOt7Rk+SRRRYccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtqMfDzEXpr5sTuNVuzYBPE2Bi6owqeb+h1kbxIVWYdC7uVGB tJ1DsK23UcLYdhI56Feqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bW5QIYrgagu5ZFbL6pbQV6yk4q0>
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, 26 Feb 2018 07:29:00 -0000

On 2/25/2018 6:07 PM, Martin Thomson wrote:

> Yes, this is a real issue.  It arises because the packet that would
> normally trigger loss detection for the request packet (the ACK for
> the Finished) never gets sent because the server believes the client
> to be quiescent.  The server believes that because it discards the
> cleartext packets that it receives.
We debated that with issue #1018
(https://github.com/quicwg/base-drafts/issues/1018). At the time, we saw
two options:

1) Allow the "finished" message to be transmitted in 1-RTT protected
packets. This was nixed because it seems to interfere with the formal
proofs of TLS 1.3.

2) Allow the server to accept retransmission of handshake packets
intermixed with 1-RTT protected packet. Clearly, this open a DOS attack,
as third parties can now inject such packets, consume packet numbers,
and possibly cause good data to be dropped.

I was not aware that the spec pushed a third alternative, to mandate
that the server to just drop handshake packets after receiving the first
copy of the finished message. As Marten says, that puts the client in a
bad position if the first ACK is lost and the server is silent after that.

The solution might be to send a "Finished received" frame in the
protected data flow, and require an ACK for that frame. That way, the
problem would really be solved.

-- Christian Huitema