IETF Logo Mail Archive

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

Mike Bishop <notifications@github.com> Thu, 12 December 2019 17:01 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 3183B1209F0 for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 09:01:53 -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 V8kYEhnkHlsr for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 09:01:50 -0800 (PST)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22B51209D2 for <quic-issues@ietf.org>; Thu, 12 Dec 2019 09:01:49 -0800 (PST)
Received: from github-lowworker-f144ac1.va3-iad.github.net (github-lowworker-f144ac1.va3-iad.github.net [10.48.16.59]) by smtp.github.com (Postfix) with ESMTP id 05A4FA0A3C for <quic-issues@ietf.org>; Thu, 12 Dec 2019 09:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576170109; bh=SFpxO2zd0LsyIopYZ+DIwuIIv4PKvzyrLu9fohZMesQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CuSKNKq+20bD61C+XIjgMw5y0RJi+h6DhKDdNLW3KWhaNo+KY5hhko8agzB2S1SBu w8MloPnCmhPIhhOI1YAdgfi9G3SLNXaikQVJf/qPEu1mj4fqqcjwiN2EYRCNDtB/xF CWlN+cscCBg9k+syKpb1IeMZMJ/xtacZF8D1ME5U=
Date: Thu, 12 Dec 2019 09:01:48 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3A6HYF6DKVIDHIMIV376SPZEVBNHHB72WFIM@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/565094294@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_5df2727ceac70_626e3ff1d3ccd96893711"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/EtGnaapxf0-1Ozm6TyFhN3-V0rI>
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: Thu, 12 Dec 2019 17:01:53 -0000

> We deliberately decided to mix crypto handshake and transport negotiation in QUIC. TP is a cross-layer thing that is exchanged during the TLS handshake.

I'm ambivalent about this assertion.  When we had a section on requirements for crypto handshake protocols, one of the requirements was to carry and authenticate the provided opaque blob.  Using a TLS extension was then the TLS incarnation of that requirement.

Since then, we've decided this version is TLS-only and future versions can figure things out for themselves. From that choice, we've opted to integrate packet types and encryption with the TLS record layer and key schedule for this version.  I don't agree that this is an area we've deliberately decided to mix layers, but I do agree that we could reasonably make that choice.  Clearly your implementation has, regardless, and I don't see that as a bad choice.

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

v2.23.0 | Report a Bug | By Email