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

Kazuho Oku <notifications@github.com> Sat, 14 March 2020 05:18 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 B5C883A0E73 for <quic-issues@ietfa.amsl.com>; Fri, 13 Mar 2020 22:18:31 -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 9lXr4mperLdm for <quic-issues@ietfa.amsl.com>; Fri, 13 Mar 2020 22:18:30 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3769B3A0E6F for <quic-issues@ietf.org>; Fri, 13 Mar 2020 22:18:29 -0700 (PDT)
Date: Fri, 13 Mar 2020 22:18:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584163109; bh=sKoJ08JMRmVL72Fi8mjj4XVfMtIcAFKtE3YSEOOdNAA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yNPFKxTlSBWYPaCkyYVBBQZd0rwINcJnhkSu75TjKegKccfpNnCIkj19QTxSiG2rH r0hF/kZhwcZl3RIs/2pQar1y2QTqipx7xfgbvpx5JZfOKyjJhmZD+nIMw815C1IOJx bMg6lhxSoLlo2l12vClh7pvk43MCEkqns44YdgnE=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYDLAKXNKIEJADRWUN4PBFCLEVBNHHCFIPTEI@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/599013462@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_5e6c692529001_27393fb282ecd960438cd"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/yLq5BnFuwAxxXV0tcd7fZHQeEjE>
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 05:18:32 -0000

I'm tempted to argue that this proposal should be considered as an extension, if we are to consider it.

Amount of data that a server might be willing to send before it confirms the client's address depends on if the server is resuming the TLS handshake. It is my understanding that the reason we require clients to pad Initial up to 1200 bytes is to provide server enough room to send the certificate chain before the client's address is confirmed. That room is unnecessary when the handshake is resumed.

However, it is questionable if a TLS server sending a session ticket is committed to getting the handshake being resumed. As an example, each server behind an anycast address might be issuing session tickets that can be only handled by the server that generated the ticket. This is fine, because resumption is considered as an "optimization."

I think we should stick to the design principle of TLS that resumption is an optimization that sometimes work, but not always guaranteed to be.

Allowing clients to send a small-sized Initial when attempting resumption goes against that principle.

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