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

Martin Thomson <notifications@github.com> Mon, 16 December 2019 01:03 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 01DDA12009E for <quic-issues@ietfa.amsl.com>; Sun, 15 Dec 2019 17:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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] 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 PWmYus_wVS4L for <quic-issues@ietfa.amsl.com>; Sun, 15 Dec 2019 17:03:56 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1A412008F for <quic-issues@ietf.org>; Sun, 15 Dec 2019 17:03:56 -0800 (PST)
Date: Sun, 15 Dec 2019 17:03:55 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576458235; bh=FuBQFfbBXQEu3Y6WT1SZTnxQhnV8wjIV5ZAyyz1mSPs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rBgricQa8sExTOCBzemMHQ09uwxiPDzSjUK1U1TZtR4QjRaMTsHfu480PPfkhD8Io HZKr2K+xDcw9rAuNQot5eyNI+B0ZAbWHg4fJ8gmYysHn8emwOFKEP1gjIlaiwI+PVn t7gNlwXh8ZtRN0bqlP6C0pIKRwjRtFbpmee2y6cw=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY3XQI7TBMQCIIE5V54AQFHXEVBNHHB72WFIM@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/565867776@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_5df6d7fb5e72e_15243ffb5e6cd95c116547a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/y4jdu8boyHX0pMg1tJTPlY-HzSQ>
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: Mon, 16 Dec 2019 01:03:58 -0000

The question here is to what extent we consider the TP encoding to be part of the QUIC stack as opposed to the TLS stack.  One school treats the transport parameters as an opaque carrier of bits, leaning on the abstract interface we have defined between transport and TLS.  The other says that implementation strategy might differ and the similarities with TLS can be exploited in some implementations.

The parallel drawn to the KDF function TLS provides is clearer - at least in my mind - about this distinction.  TLS provides a KDF in the form `KDF(secret, label, output_length)` that QUIC uses.  We did at various points in the process consider modifications to that KDF, but the current form is very clear about leaving the KDF function unmodified.

I think are more pertinent questions here is the relative cost change against the improvements that might be gained.  The advantage of retaining the current form is that it can be more tightly integrated into a TLS stack.  The advocates for change see the potential for removing a single instance of bespoke encoding from the QUIC stack, plus a modest reduction in handshake size.

We've heard that at least one implementation would find changes to be disruptive.  I might separately observe that disruption to an existing implementation is not a great motivation for opposing a change on its own, because we all knew the risks when we decided to build to a draft specification.

If we were to make arguments from some principled basis, I would say that the bag of bits view holds: QUIC is responsible for constructing and consuming transport parameters as an opaque blob.  But that's not really a useful basis for making a decision when there are more substantive matters at stake.

-- 
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-565867776