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

Christian Huitema <notifications@github.com> Sat, 14 March 2020 19:02 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 670613A0A8B for <quic-issues@ietfa.amsl.com>; Sat, 14 Mar 2020 12:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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_24=1.618, 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 HOiysWnaaLdr for <quic-issues@ietfa.amsl.com>; Sat, 14 Mar 2020 12:02:07 -0700 (PDT)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13B63A0A2B for <quic-issues@ietf.org>; Sat, 14 Mar 2020 12:02:06 -0700 (PDT)
Date: Sat, 14 Mar 2020 12:02:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584212525; bh=zrYwU4XVAfxO0wVc0atdBnu2nM3RO+l++8ShjBusLGM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BBulAsk83oeVP6GS7y92cXxMH/kb03Czq0/lOuko63U5MKpJ4fAM5fK/D5fpl6LLK CvQ5I/7uAeHu9JGGHy1GuXUZmruIGpPE+ecHOMR9VL7SikVkib1d4FLqQFFkaD88vB JK8rUs6lxSdtEcHG0PuyHv/N6J63V+IYE/B6Gx5c=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2Y4FOBJDDJ4SZROVV4PEFS3EVBNHHCFIPTEI@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/599121809@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_5e6d2a2dd6621_26d93ffbc5ecd960611f5"; 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/gQMnvVEOgSOv5JgCj3QeBTIWLRk>
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 19:02:11 -0000

This scenario is not a great fit for the extension mechanism. Extensions are normally negotiated using transport parameters. We could see an exchange such as:

* Client: set "minimal_initial_packet_size = 512"
* Server: set "minimal_initial_packet_size = 768"

After which the client would remember the minimal initial packet size for this application as the maximum of the client proposed value and the server proposed value, or 1200 if either the client or the server do not set the parameter. The client could then remember that value with the session ticket, and use it for resumed connections.

But the client would not be able to use this for the first exchange with the server -- that's the limit of our extension mechanism. If we want shorter first packets in general, the alternate minimal initial has to be part of the application specification.

On the other hand, even an application specification is a bit problematic if the server multiplexes several applications and demuxes on the ALPN. The server will only be able to verify that the size is OK after obtaining the ALPN, which means after processing the Initial packet. With the current spec, the server can reject packets too short before doing any processing.

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