IETF Logo Mail Archive

Re: [quicwg/base-drafts] Describe inputs to TLS more clearly (#4011)

Kazuho Oku <notifications@github.com> Tue, 18 August 2020 04: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 D0FF23A170E for <quic-issues@ietfa.amsl.com>; Mon, 17 Aug 2020 21:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 ehOaummcg8ML for <quic-issues@ietfa.amsl.com>; Mon, 17 Aug 2020 21:03:17 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F8F3A1711 for <quic-issues@ietf.org>; Mon, 17 Aug 2020 21:03:17 -0700 (PDT)
Received: from github-lowworker-c73936b.ash1-iad.github.net (github-lowworker-c73936b.ash1-iad.github.net [10.56.112.13]) by smtp.github.com (Postfix) with ESMTP id A4724560E04 for <quic-issues@ietf.org>; Mon, 17 Aug 2020 21:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597723396; bh=7zt38Wtha6YWn0X+T58CwsaaSYNup6SWwgmTEzQQyQ0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PNL+rrrpJ5/D4nuZivGyaYvbaTtYlCLeGTFIQQDUOHvwbIYW4czvDIyNrmRtWl8eu w+tZy/0SkfiaaE7oI6xS07BSsBR9Ckyvw2w5BiabGDzGpcs1KYS08Egww2s4bXOZq1 /GeNFaTkHm6w/LjPJpoJzS0MEE2gty9YdCEDOjVg=
Date: Mon, 17 Aug 2020 21:03:16 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2RIF753R6OVLE26IN5I42AJEVBNHHCRENCFU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/4011/c675235920@github.com>
In-Reply-To: <quicwg/base-drafts/pull/4011@github.com>
References: <quicwg/base-drafts/pull/4011@github.com>
Subject: Re: [quicwg/base-drafts] Describe inputs to TLS more clearly (#4011)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f3b530493c1e_3d14196491433"; 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/-Rzu9mq3-5TAZhkzMrenFXdYZYk>
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: Tue, 18 Aug 2020 04:03:19 -0000

Weren't we going to say that the traffic keys might get generated asynchronously in #3874? I wonder how this PR interacts with #3874.

I see this PR calling out three types of events (i.e. generation of CH, input of handshake bytes, completion of certificate validation) as the "inputs," then claim that TLS provides the keys "synchronously" in relation to such events. That works as a definition, but I am not sure if it is easy to comprehend.

I think my preference would be to talk about (a)synchronicity from the viewpoint of a transport. It would be easier to say that TLS might provide keys "asynchronously" from what the transport provides as input, then point out that key generation (possibly in relation to certificate verification) might take some time.

-- 
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/pull/4011#issuecomment-675235920

v2.31.3 | Report a Bug | By Email | System Status