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

Kazuho Oku <notifications@github.com> Mon, 16 December 2019 00:27 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 C1CFE12009C for <quic-issues@ietfa.amsl.com>; Sun, 15 Dec 2019 16:27:37 -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 DINouwj2fJak for <quic-issues@ietfa.amsl.com>; Sun, 15 Dec 2019 16:27:36 -0800 (PST)
Received: from out-12.smtp.github.com (out-12.smtp.github.com [192.30.254.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E6F12008F for <quic-issues@ietf.org>; Sun, 15 Dec 2019 16:27:36 -0800 (PST)
Date: Sun, 15 Dec 2019 16:27:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576456055; bh=nFqXc2f5xOSqBK16udjCOYzRoilAnlHiC32pTWuis6c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Y9b/K9TMaQBhjh7GXdHicynxInvimwswkEzkwIgPXjTz4BLNyTPT7hC+CCHlUK+SG pLqxjA3o/kjH3aDpvsUuDd/hiDGPUiWqarB35vyHGy1ccCr9kTNp4viKigUcMK1x5o sxSUngNt7zgHDLzaHvagOYvrmbq4wYiI5cYFmujo=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2WRORGJUBMUJKJT4N4AQA7PEVBNHHB72WFIM@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/565863737@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_5df6cf7771bab_51dc3f99bd0cd96010261de"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/56koGf9vzsAPtdaflU6FQJ7d8L4>
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 00:27:38 -0000

@MikeBishop I think I mostly agree with the observation.

Draft-12 essentially changed QUIC to a TLS record layer. QUIC now has four record types because that is what TLS 1.3 has. The key discards are designed based on how TLS 1.3 starts using new keys (i.e. handshake key is used by the server first, and the client is the last to use it).

And moreover, there is another instance we use uint16, in addition to TPs. That is through the use of `HKDF-Expand-Label` function of TLS.

QUIC uses `HKDF-Expand-Label` for deriving protection keys from traffic secrets generated by TLS. As the derivation and use of protection keys is specific to QUIC, we could have directly invoked the `HKDF-Expand` function defined in [RFC 5869](https://tools.ietf.org/html/rfc5869). But in status quo, QUIC uses `HKDF-Expand-Label`, defined in TLS 1.3, which [has a uint16 field in the Label encoding](https://tools.ietf.org/html/rfc8446#section-7.1).

To me, this looks like an example of encouraging code reuse, much like the use `uint16` for encoding TP ID and lengths.

If our principle is going to be to minimize the interface between TLS and QUIC, we should consider changing the points I've stated above.

Or if our principle is to encourage (or leave room for) code reuse between TLS and QUIC, the encoding of TP IDs and lengths should be kept as-is, along with the use of `HKDF-Expand-Label`, how we drop keys, the use of four epochs ...

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