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

Christian Huitema <notifications@github.com> Sat, 14 March 2020 18:14 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 55F0B3A0922 for <quic-issues@ietfa.amsl.com>; Sat, 14 Mar 2020 11:14:24 -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 PqsqdlaINAjk for <quic-issues@ietfa.amsl.com>; Sat, 14 Mar 2020 11:14:23 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DF13A0921 for <quic-issues@ietf.org>; Sat, 14 Mar 2020 11:14:22 -0700 (PDT)
Received: from github-lowworker-d93c4b6.va3-iad.github.net (github-lowworker-d93c4b6.va3-iad.github.net [10.48.17.47]) by smtp.github.com (Postfix) with ESMTP id 268092C0E8A for <quic-issues@ietf.org>; Sat, 14 Mar 2020 11:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584209661; bh=73tSJuBP2gMBqeyx43xGYx5YRtJY8Vqc89VWMdaTLr4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ecxTUjV/qtu/XuRgDCVZtHUm6KhS5ta+2OScCQM1m4VIVYEtMNAxNjIrgq0PTXKi1 Dnx7237Xi7k0fKUZ/tFGDtMQqHkrEzgdA+krIYQVuWjO6zkjW8ZgAXIiMD58nID1we so0cTcwQtYHTB3FWwaiHgusLALjoL1XX0vFqO5Rs=
Date: Sat, 14 Mar 2020 11:14:21 -0700
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZC44R6RP6NVSPKDKN4PD773EVBNHHCFIPTEI@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/599113691@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_5e6d1efd17331_74493fce262cd95c176416"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/7vrOACGvqIQq9inlBvQ6nS-mAvU>
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, 14 Mar 2020 18:14:24 -0000

If we are happy with the factor 3 amplification limit, the practical minimum is "one third of the server's first flight". If we go below that, then the server flight has to be split over several RTT, which is bad for latency. I wonder what the flight's minimum is. Can we rely on certificate compression? How big is the signature? What of post-quantum, or hybrid techniques?

I was initially focusing on the "token-authenticated" case, because that's less exposed to DDOS than the general case. It is also a good fit for the DNS scenarios, with intermittent connections to a small number of big servers. But a global solution would be even better.

Something like, the initial packet can be as small as 512 bytes, but the server can never send more than 3 times that before validating the connection. And clarifying what validating means in the "new token" scenario.

-- 
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-599113691