IETF Logo Mail Archive

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

Nick Banks <notifications@github.com> Wed, 11 December 2019 15:19 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 D97831208C0 for <quic-issues@ietfa.amsl.com>; Wed, 11 Dec 2019 07:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_28=1.404, 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 40W1oCFWhtZU for <quic-issues@ietfa.amsl.com>; Wed, 11 Dec 2019 07:19:11 -0800 (PST)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD75120896 for <quic-issues@ietf.org>; Wed, 11 Dec 2019 07:19:00 -0800 (PST)
Received: from github-lowworker-f62aa54.va3-iad.github.net (github-lowworker-f62aa54.va3-iad.github.net [10.48.17.68]) by smtp.github.com (Postfix) with ESMTP id 63088A043E for <quic-issues@ietf.org>; Wed, 11 Dec 2019 07:18:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576077539; bh=bHUwj/yCIXXYyNoxA0q+ZsH7Q527i7OF1zYlSz6aDMQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yB1SP/3+ZpIomQ8bNzuql6B4tGR94ahCDvrhKeWbDAK9o1B+9H81Sk6mjj9+0WtJb 18jsDlQpR6pVU2xxSg/R3aWVMEAmi1M/DAE8a8tM00sgNdfyOz1J/qWwp2tYQvMrbx 7jwVTNXJ6MOHX/g6wU5GkB9b5ix+7220KR85TNRM=
Date: Wed, 11 Dec 2019 07:18:59 -0800
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5J7QLQNRD6NNQBKK537Y5WHEVBNHHB72WFIM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3294/564592324@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3294@github.com>
References: <quicwg/base-drafts/issues/3294@github.com>
Subject: Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df108e3539de_66fc3fb8490cd96015722b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/_2VF8OKXUtKvxGt95e1PDDGp5w8>
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, 11 Dec 2019 15:19:13 -0000

I support this change for a numbers of reasons:

1. The QUIC layer is the one that reads and writes the contents of the TP, not the TLS layer. QUIC libraries cannot be dependent on TLS libraries to encode/decode the individual parameters. QUIC and TLS should be independent enough, so that they can evolve in parallel, without requiring changes to both, whenever one changes. Not to mention, not all/many TLS libraries will/do expose this type of functionality already.
2. No where else in the QUIC code/spec do I need to use or understand TLS encoding. This shouldn't be an exception to that.
3. The current encoding TLS scheme requires an extra, unnecessary length field for the whole TP, because of how TLS presentation language specifies the list of parameters. IMO, this just makes the code more awkward and I'd like to be able to remove it.

-- 
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/3294#issuecomment-564592324

v2.23.0 | Report a Bug | By Email