Re: Unrecoverable loss pattern

Christian Huitema <huitema@huitema.net> Mon, 26 February 2018 18:45 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 DF387126C3D for <quic@ietfa.amsl.com>; Mon, 26 Feb 2018 10:45:34 -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 CONn5gEeuPKc for <quic@ietfa.amsl.com>; Mon, 26 Feb 2018 10:45:33 -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 54F6F124D6C for <quic@ietf.org>; Mon, 26 Feb 2018 10:45:33 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx64.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eqNmF-000AvM-4v for quic@ietf.org; Mon, 26 Feb 2018 19:45:31 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eqNlh-0004NW-Le for quic@ietf.org; Mon, 26 Feb 2018 13:45:29 -0500
Received: (qmail 23306 invoked from network); 26 Feb 2018 18:44:55 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 26 Feb 2018 18:44:55 -0000
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Marten Seemann <martenseemann@gmail.com>, 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> <f62726b4-564a-4e45-726b-63705753ddf2@huitema.net> <CABkgnnU78mE55N9KHx2FqR6AvthyM86-+zG-VknQ3tfpeKh=Gw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <9d646ca7-2c95-62fd-206f-10ec6ce4cd5d@huitema.net>
Date: Mon, 26 Feb 2018 10:44:51 -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: <CABkgnnU78mE55N9KHx2FqR6AvthyM86-+zG-VknQ3tfpeKh=Gw@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.223
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.17)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5gXivFKqF+MRRSOkXJxbbal602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViW4Iybcz83Dow0ZgaOTB9U87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBmePYa3CQqb9L6x2mHOMrWx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYJlgC/j6gnFfUz8cFIW+v ZP5XHG7O1tYu81mRrWwAsv7c/F7BDvT0aUBvAh6gJldfpXIull5ERhEWeEevzAF7zmj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBENq HXIoSsvffuCdDqwWbJR1D/7Rwl5fb+U9Gl2IOh9znuhk/x9yoQRTGrDa4+HCd27Q+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amRbl6gc+xGfFxqO6pPmlSScERpFEqF2lExBUp1VMiBudJzjv VlSk5R4XVB7M44lU2DF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kBL3okSjkAIxO4fgXkeAIJPO04U>
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 18:45:35 -0000


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