Re: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)

ekr <notifications@github.com> Thu, 10 October 2019 03:55 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 9744B1200B2 for <quic-issues@ietfa.amsl.com>; Wed, 9 Oct 2019 20:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 4UtN771QfSZc for <quic-issues@ietfa.amsl.com>; Wed, 9 Oct 2019 20:55:02 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9969F12006D for <quic-issues@ietf.org>; Wed, 9 Oct 2019 20:55:02 -0700 (PDT)
Received: from github-lowworker-45eca55.ac4-iad.github.net (github-lowworker-45eca55.ac4-iad.github.net [10.52.25.70]) by smtp.github.com (Postfix) with ESMTP id 983B0520839 for <quic-issues@ietf.org>; Wed, 9 Oct 2019 20:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570679701; bh=H69X/liplVNNEo8MojGOtfEK8H/VHgRoJpT0vObw0zw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qeFKmm9F0EM8Euq7JtP65T7HkgLLPXaTQ4Rg4Nsh7LwOdksF7E3jX5V56XV8/h2by uszC8rryih37erqp/q0Nt5dYFmg4qymo5UB/kfQXkGHzCWtIqrU57z5xmw9t8B+Hye PGBTkXAv2SnIXrCO829enboWJuPA9nWStCFFTa9s=
Date: Wed, 09 Oct 2019 20:55:01 -0700
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2ENJ5GL25XPWNBGAF3VPWCLEVBNHHB3EM4KU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3053/540335959@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3053@github.com>
References: <quicwg/base-drafts/issues/3053@github.com>
Subject: Re: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9eab9588c70_23093fd6aaacd968103135"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/5RXJYAxrnzijoChi_3zijzZZwWo>
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: Thu, 10 Oct 2019 03:55:05 -0000

> If you are sending Initial, it is possible that this is the only packet in the datagram that can be processed by your peer. If that is the case, then a client needs to ensure that it pads the datagram as though no other packets were present.

I don't know where you get this from. It's total datagram size that matters, not the contents of the rest of the datagram (which is why the neqo padding strategy works).

Anyway, the algorithm you propose seems fine, but it's not necessary, and therefore there's no need to specify it in the spec.

-- 
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/3053#issuecomment-540335959