IETF Logo Mail Archive

Re: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)

Nick Banks <notifications@github.com> Tue, 17 March 2020 23:10 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 9C17A3A09ED for <quic-issues@ietfa.amsl.com>; Tue, 17 Mar 2020 16:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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, 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 ct18SGVgMgB3 for <quic-issues@ietfa.amsl.com>; Tue, 17 Mar 2020 16:10:04 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03CF3A09E1 for <quic-issues@ietf.org>; Tue, 17 Mar 2020 16:10:03 -0700 (PDT)
Received: from github-lowworker-3a0df0f.ac4-iad.github.net (github-lowworker-3a0df0f.ac4-iad.github.net [10.52.25.92]) by smtp.github.com (Postfix) with ESMTP id 3664D8C1633 for <quic-issues@ietf.org>; Tue, 17 Mar 2020 16:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584486603; bh=2q223A4q8EnNJLx5GJPGtBuvM+d6Qqgr7XRpX1uwyr8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ibsnJOtx9/zStdrlVsodNN38PLQR9BZ7vwHg3VmQPulXTyuDE9qb3ybEGwXlQJbMn bip7MgSxccYa7XFYYeSGQ45dB1MUxnuFGUfaq36nH++nL7g2BeBsHgBu37YAXYMRTQ 4JGCLZUPC0QwtOWH9kk7Ap3NETR8M45j8KSSXdaQ=
Date: Tue, 17 Mar 2020 16:10:03 -0700
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6PXSGPZNWT2V6TVGF4PU44XEVBNHHCFIPTEI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3523/600343706@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3523@github.com>
References: <quicwg/base-drafts/issues/3523@github.com>
Subject: Re: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7158cb25e21_6aa03f87738cd96410237"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/9op0LtV-y3fhOJR3vYgyEEQxPEY>
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: Tue, 17 Mar 2020 23:10:08 -0000

FYI, for MsQuic it would be difficult to make kind of decision based on an extension (TP). This logic happens statelessly, without processing the payload of the packet. If we had to change the logic to possibly always accept the packet far enough into the recv pipeline to look for a TP, that would be a really big change. What if the TP isn't in the first packet of the client initial (multi-client-initial)? Now the attacker can send an even smaller packet to make me (the server) hold state, while I wait for a TP that might not come to decide if that first packet was big enough?

Making a new version would be the only reasonable solution, IMO.

-- 
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/3523#issuecomment-600343706

v2.23.0 | Report a Bug | By Email