Re: [quicwg/base-drafts] This seems like tuning (#4020)

Mike Bishop <> Wed, 19 August 2020 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AEB73A0D99 for <>; Wed, 19 Aug 2020 12:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uFV0mTebyTIx for <>; Wed, 19 Aug 2020 12:49:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC4FB3A0D9A for <>; Wed, 19 Aug 2020 12:49:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 32A5DE0019 for <>; Wed, 19 Aug 2020 12:49:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1597866570; bh=FSYzI/9Lefp7viZncNsPbp5oigdKYSKRJNIryduJRLY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Cu4EkXomHnOdeQHH68DgKgEQAKcCgsUt9GJXiadQqxlqwD2jUCPSKS/PmI/oT941Y 0htnu3Snm1h0LEgSGWkzj9xTl70CJlfCDXt3zmuYge+ULDK9kXcGQ5SYkCirKBZIi8 4SYziax37eWo/x8FunSSj3i1qe/CVO3tTfZT1Seo=
Date: Wed, 19 Aug 2020 12:49:30 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/4020/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] This seems like tuning (#4020)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f3d824a2335b_75c919642028de"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Aug 2020 19:49:34 -0000

> The first packet for an unsupported version can use different semantics and
encodings for any version-specific field.  In particular, different packet
protection keys might be used for different versions.  Servers that do not
support a particular version are unlikely to be able to decrypt the payload of
the packet.  Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, provided that
the packet is sufficiently long.

I'm having trouble seeing what's needed here.  The endpoint has received a packet professing to be in a version it does not understand.  It can't know the semantics or encoding of any field there -- and the paragraph already explains that.  Yes, I'm sure there are potential attacks in interpreting a packet of unknown provenance and unknown semantics against a different set of semantics and expectations, but I'm not convinced we need to explain them.  The text recommends sending a Version Negotiation packet, which seems like the only sensible response.

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