Re: [quicwg/base-drafts] Handshake loss recovery interacts poorly with amplification attack defense (#1764)

Martin Thomson <notifications@github.com> Sat, 22 September 2018 16:41 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0662D130E2E for <quic-issues@ietfa.amsl.com>; Sat, 22 Sep 2018 09:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 aoNyfER5xS9t for <quic-issues@ietfa.amsl.com>; Sat, 22 Sep 2018 09:41:52 -0700 (PDT)
Received: from out-9.smtp.github.com (out-9.smtp.github.com [192.30.254.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E35A130E26 for <quic-issues@ietf.org>; Sat, 22 Sep 2018 09:41:52 -0700 (PDT)
Date: Sat, 22 Sep 2018 09:41:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1537634511; bh=L3xFV4LhKho57bf1CVpAvkIc+vl/xWEGklQwSj1Fkog=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p0oMj4rcjsK8XXnzx421FiPGi8SADuIfDHSaWcIYojNmYoTNmeDq80oup6PklmwTn SYr0cCQiVJdqYXdgbFI4XcGYniJPmeQaDhABGikHmdej8sNjeijywQEhaCzGUK2OHP XDoFZrTULFeIQhvc1vcxJiWn+IhAjibbvNyE3V08=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab248b86a391682f90ed4f719d1e8d4d420d35e01a92cf0000000117be32cf92a169ce1589cd31@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1764/423756834@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1764@github.com>
References: <quicwg/base-drafts/issues/1764@github.com>
Subject: Re: [quicwg/base-drafts] Handshake loss recovery interacts poorly with amplification attack defense (#1764)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ba670cf84cdf_55973f9aaccd45c01759e4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/0QudTlF03CUZ4gGMFnEAGRTB5NM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Sep 2018 16:41:54 -0000

I had a different conception of this.  That is, the client runs the Initial timer fairly aggressively for longer.  That is, you set a timer for retransmitting Initial+ClientHello and rather than stopping that timer when you get a packet from the server, you stop it when either the handshake completes (or you receive an ACK in a Handshake packet).

The tweak being that you can send Initial with the ClientHello in it, but then switch to sending anything else when you've received proof that the server got your message (basically, any response other than Retry).

At that point, it doesn't matter what you put in the packet.  I was thinking that triggering standard retransmission logic would be bad in this case because you don't really have anything to send, it's just a matter of giving the server primed enough incoming bytes that it can send enough outgoing.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1764#issuecomment-423756834