Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

Kazuho Oku <> Wed, 11 December 2019 08:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF9D81200E9 for <>; Wed, 11 Dec 2019 00:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 al-qz81Mu_Ep for <>; Wed, 11 Dec 2019 00:54:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16B051200A3 for <>; Wed, 11 Dec 2019 00:54:13 -0800 (PST)
Date: Wed, 11 Dec 2019 00:54:12 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576054452; bh=Kbe9pE6bvZXHQw2//gdATwjHmnvbvPU5B8L8Dnj58G0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=aCgQ7hi72ITkGz+33IMga6HvpAKU37sg7sOWG770InNFbtTOsf+oc9tpGQhvNiFPW IICrLn2HqhobFERqBNL0lV720YkHVpAIvSsc+j8LdziWu/yvrnOwxCjQixdbRC4Mz1 jXrqYLrlPWlk3VcV6cToJ3ywAx+Nbzztp6JVSKT4=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3294/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df0aeb42ca59_2103fd153ccd96877346"; 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: Wed, 11 Dec 2019 08:54:15 -0000

> If I remember correctly, the main argument for giving up on the TLS notation was improved readability for people who are not familiar with TLS representation language.

Re moving away from TLS notation, my memory is consistent to what you describe.

> From the viewpoint of consistency in encoding, switching back to it would definitely be an improvement though.

I think you make a good point here. Assuming that we keep the status quo, it would be helpful to the readers if we explained why it is designed as such. Maybe something like following would be a good idea: _To encourage code reuse, the encoding and validation requirements of Transport Parameters follows that of TLS extensions (RFC 8446; section 4.2](

> That being said, I still don't understand why TLS should be involved with the encoding of a value that it never treats as anything other than an opaque blob.

This is the only case in QUIC where we need to skip an opaque value of unknown type. That's why we use a type-*length*-value. We are also required to check that each parameter appears at most once, and also that the length of known parameters are as expected.

These requirements happen to be exactly equivalent to what is required for TLS extensions. And therefore it is beneficial *if* the existing code in TLS stack can be reused. Considering that QUIC already has a pretty tight coupling with TLS, I do not think it is unnatural to endorse such reuse.

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