Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)

ianswett <notifications@github.com> Thu, 22 October 2020 21:50 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 EE0AF3A1106 for <quic-issues@ietfa.amsl.com>; Thu, 22 Oct 2020 14:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Udam_eam4gnl for <quic-issues@ietfa.amsl.com>; Thu, 22 Oct 2020 14:50:28 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C303A1105 for <quic-issues@ietf.org>; Thu, 22 Oct 2020 14:50:28 -0700 (PDT)
Received: from github.com (hubbernetes-node-d10fef6.ac4-iad.github.net [10.52.110.27]) by smtp.github.com (Postfix) with ESMTPA id ECB8D560055 for <quic-issues@ietf.org>; Thu, 22 Oct 2020 14:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1603403427; bh=ka5DqRgl/JUbeTAh3hhnVXOu6yre+BY8PY9TLz2LX6Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZTcTdZRhDa7FDKNKzG0QHOVIWVlecoi1jAV3MeXWTtLBEdSHObKvpp3gJ0EssKKXE Q7C4qhSFayytzvaxhB2ISbFyn5xBTDTyjaEvV+ebQDLUcwurqW7K70S3rMIOTaZTGs 8NLcd3IqXdhSqUloFGJt4rxwXO0W8v7dO6eEFYOI=
Date: Thu, 22 Oct 2020 14:50:27 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4DLNG5HWDWC6UWTH55TXP2HEVBNHHCWUAGFQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4257/714782326@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4257@github.com>
References: <quicwg/base-drafts/issues/4257@github.com>
Subject: Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f91fea3e94cd_4f19b41055d2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/itog1ts2U-LEhiaQM3mjXj8paTo>
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: Thu, 22 Oct 2020 21:50:30 -0000

I think leaving this alone and focus on clarification SGTM.

Amplification limits are tricky, as evidenced by the repeated tweaks we've needed to enforce the 3x limit during the handshake, so adding one at this stage sounds risky.

Given there is some 'protection' by requiring the handshake to complete prior to migration, I think this protection is sufficient as long as one can't repeatedly abuse migration by immediately migrating over and over.  I'm not sure if the existing text provides enough protection or not from that situation or not?


-- 
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/4257#issuecomment-714782326