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

Christian Huitema <> Wed, 18 March 2020 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67E393A0BF0 for <>; Tue, 17 Mar 2020 17:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.554
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JmUDl2eZvSOf for <>; Tue, 17 Mar 2020 17:06:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDFF33A0BEE for <>; Tue, 17 Mar 2020 17:06:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E43286A11B7 for <>; Tue, 17 Mar 2020 17:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584489967; bh=HGhaXXrKz0+HRsSyVYAZGUX+Xk3Ear294unTQzbXuc4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GGICzaczil4+BexEISdAaVQbiO+jNNr6T3e2eFdwjWC1KcIkAwCMZgrutDzCKslx1 Ia7D43jJYX+jTsRY1M6/JviQdYt4wOIPQ/XHNRCgVmNFLYwmGbjRXpe2E0SBogguhT vx49i9Cc81Wzfx9XpDGkP8k0VWF6lc9vhsaJrZTQ=
Date: Tue, 17 Mar 2020 17:06:07 -0700
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3523/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7165efd37ca_3ffa3f896decd96c2004ba"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Mar 2020 00:06:11 -0000

I don't like the idea of creating a version of Quic especially for DNS over Quic, because of the privacy implications. Of course it could be negotiated and remembered, but then it looks like painting the packets with a big target for various kinds of firewall filtering. But then using shorter initials also paints a big target.

I also don't advocate holding V1 at the gate to solve that. I like the suggestion to allow shorter initial packets and to limit the number of bytes that the server sends. But i get that we may want to wait for V2 for that.

For now, I will concentrate on other optimizations, such as limiting the packet overhead. That can be done with implementation guidance.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: