[quicwg/base-drafts] Client that does not PAD does not negotiate? (#4021)

Lars Eggert <notifications@github.com> Wed, 19 August 2020 14:32 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 2A8B73A0B2F for <quic-issues@ietfa.amsl.com>; Wed, 19 Aug 2020 07:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 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, RCVD_IN_MSPIKE_H2=-0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KxJVYYb4xbTr for <quic-issues@ietfa.amsl.com>; Wed, 19 Aug 2020 07:32:38 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F003A0ABE for <quic-issues@ietf.org>; Wed, 19 Aug 2020 07:32:37 -0700 (PDT)
Received: from github-lowworker-0f78100.ash1-iad.github.net (github-lowworker-0f78100.ash1-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 4D1FF600E30 for <quic-issues@ietf.org>; Wed, 19 Aug 2020 07:32:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597847557; bh=k5AqrRrbJVr4zN20cdfyij/Zgnaf+AKejGgdVbNu4T0=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=NwqvMFj8BYth3ceiD2TXDEBSUj/Bpj5/secuP8uyPfymUVJ0o9dqF8GAdv1ogZlVP UShjwYTc0juTVSyqd7mZn1Vq/h9rCu9+FuWyrTsfiYJexRYI3QvsRXpqwIhJ6fLqmV LCGHLpvEs+vWa8uEg0DDKR2EQYZGbgB6YFga9Et4=
Date: Wed, 19 Aug 2020 07:32:37 -0700
From: Lars Eggert <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ5IHOQN3JIIQOZW355JEMQLEVBNHHCRJGOKE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4021@github.com>
Subject: [quicwg/base-drafts] Client that does not PAD does not negotiate? (#4021)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f3d38053d448_4993196454994"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: larseggert
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/3yCmtKNQlPIHsB6rwoRVUiOQbvo>
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: Wed, 19 Aug 2020 14:32:39 -0000

(Broken out of #3214.)

> The size of the first packet sent by a client will determine whether
>   a server sends a Version Negotiation packet.  Clients that support
>   multiple QUIC versions SHOULD pad the first packet they send to the
>   largest of the minimum packet sizes across all versions they support.
>   This ensures that the server responds if there is a mutually
>   supported version.

- Are you saying a client that does not PAD does not negotiate? If so: What is the logic behind that design decision?
- I don’t read that as it assures what it say. To me, the padding assures the client can send this side of packet to the remote endpoint.
- Does this agree with what is written in section 8.1 on padding? and Section 14?

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