Re: [quicwg/base-drafts] QUIC Ossification (#2496)

Kazuho Oku <> Tue, 05 March 2019 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9598F130FBD for <>; Mon, 4 Mar 2019 23:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 tPCr7DGP0nE5 for <>; Mon, 4 Mar 2019 23:01:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDEE6130FCE for <>; Mon, 4 Mar 2019 23:01:07 -0800 (PST)
Date: Mon, 04 Mar 2019 23:01:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1551769266; bh=ak/mf8hM38Wl5TnpZmmyBftxLy0TGBtD2V/duzv+NIw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xWQp0j1IdQYC0AaNKg4+Rtg1k1fZiB/3R8vj5+5srX32gISdn8GcBbYJiTgL5vQJx ulUIGwdzr36/5+Pq4AU8+4GN19RdeMxvaTVYU0OoPl7Gv8MMBU6wJogFyOcfhkcmSG CYImtOUhEIXysiDzb71S2tBME+J5UqrCPOGWME0U=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2496/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] QUIC Ossification (#2496)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c7e1eb27fad6_2a8e3fe8714d45c4667917"; 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
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: Tue, 05 Mar 2019 07:01:12 -0000

> Are there any changes to VN we can make to reduce the chance of ossification happening?

We only have obfuscation to protect the payload format of Initial packets from ossification. Therefore, IMO the question is if we can have something similar for the version number field, without making the protocol complex.

As some have pointed out, using multiple version numbers on wire to designate "version 1" is one way to go. That would be sufficient as a protection against middlebox vendors who try to use the version number field in some ways in negligence. I also think that that might be the only thing that we can do without making the "version number obfuscation scheme" an invariant.

We could do various things if we think that it is a good idea to make the obfuscation scheme an invariant. For example, we could set the version number field to a XOR value of the version number and four octets that follow the DCIL/SCIL fields (i.e. `version_number_field = version_number XOR packet[6..9]`). Such scheme would IMO require the middlebox vendors to actually consult the specification when they try to detect the QUIC protocol version. In other words, it would be as reliable as the AES-based ossification scheme we use for Initial packet payload.

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