Re: [quicwg/base-drafts] Describe interaction between QUIC and TLS regarding saved 0-RTT state (#2947)
Nick Harper <notifications@github.com> Thu, 22 August 2019 23:24 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 6AB011200E3 for <quic-issues@ietfa.amsl.com>; Thu, 22 Aug 2019 16:24:09 -0700 (PDT)
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 XoO5jslHq3bJ for <quic-issues@ietfa.amsl.com>; Thu, 22 Aug 2019 16:24:07 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709BE1200BA for <quic-issues@ietf.org>; Thu, 22 Aug 2019 16:24:07 -0700 (PDT)
Date: Thu, 22 Aug 2019 16:24:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1566516246; bh=VvJ5wFG3ZgNG2WaedptN4JMG+LMIeLL6xla5vjm7jgI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YCSSReawMHoLEeM22ZL9ccZ7IuyybHs+fRugywH98GhEraMHTfBGo2/efb0/bNb7p BYX1NTqm2fQzsE+SiIrHp6LiHDASWmFSZ05/eK6xAOUvxgvRSe/wThi50f+F2nedBT UVagLW4NUzinxT7dYAP5YEwBuCp2NSBPSangGcPY=
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2YWGII5CLD5BM5JHV3NRLJNEVBNHHBYXLIMY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2947/review/276792866@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2947@github.com>
References: <quicwg/base-drafts/pull/2947@github.com>
Subject: Re: [quicwg/base-drafts] Describe interaction between QUIC and TLS regarding saved 0-RTT state (#2947)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d5f241681a8a_293f3f979e2cd95c847cd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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/aeI8ibZxL226je1GFsVpqx-ukgA>
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, 22 Aug 2019 23:24:09 -0000
nharper commented on this pull request. > @@ -279,13 +279,14 @@ components: protection being called out specially. ~~~ -+------------+ +------------+ -| |<- Handshake Messages ->| | -| |<---- 0-RTT Keys -------| | -| |<--- Handshake Keys-----| | -| QUIC |<---- 1-RTT Keys -------| TLS | -| |<--- Handshake Done ----| | -+------------+ +------------+ ++------------+ +------------+ +| |<---- Handshake Messages ----->| | +| |<- Validate 0-RTT parameters ->| | +| |<--------- 0-RTT Keys ---------| | +| |<------- Handshake Keys -------| | +| QUIC |<--------- 1-RTT Keys ---------| TLS | Moved up a line, and moved QUIC right one column. > @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet. These packets do not signify rejection of 0-RTT. +## Validating saved 0-RTT state + +When a server receives a ClientHello with the "early_data" extension, it has to +decide whether to accept or reject early data from the client. Some of this +decision is made by the TLS stack (e.g. checking that the cipher suite being +resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC +saves additional transport and application state in a 0-RTT session ticket, and I think we're trying to say the same things, just in different ways. My mention of saving state was assuming stateless session tickets; now it describes that servers must associate transport/application configuration with the TLS session ticket in addition to mentioning storing state in stateless session tickets. I've rewritten most of this paragraph incorporating some of your language here. My overall goal of this section is to describe the features that a TLS stack needs to provide for QUIC (without prescribing API design). > @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet. These packets do not signify rejection of 0-RTT. +## Validating saved 0-RTT state Done. > @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet. These packets do not signify rejection of 0-RTT. +## Validating saved 0-RTT state + +When a server receives a ClientHello with the "early_data" extension, it has to +decide whether to accept or reject early data from the client. Some of this +decision is made by the TLS stack (e.g. checking that the cipher suite being Done. > +## Validating saved 0-RTT state + +When a server receives a ClientHello with the "early_data" extension, it has to +decide whether to accept or reject early data from the client. Some of this +decision is made by the TLS stack (e.g. checking that the cipher suite being +resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC +saves additional transport and application state in a 0-RTT session ticket, and +imposes additional restrictions on when a server may accept early data. The TLS +stack needs to check with the QUIC stack whether this saved state is valid for +accepting early data. + +One example of such state that the QUIC stack checks when deciding whether or +not to accept early data is the transport parameters extension. When HTTP/3 +({{QUIC-HTTP}}) is used at the application layer, the SETTINGS frame from the +previous session is another such example. This list is not intended to be +exhaustive; future applications using QUIC may impose different restrictions. I incorporated similar language into the new/rewritten paragraph. > @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet. These packets do not signify rejection of 0-RTT. +## Validating saved 0-RTT state + +When a server receives a ClientHello with the "early_data" extension, it has to +decide whether to accept or reject early data from the client. Some of this +decision is made by the TLS stack (e.g. checking that the cipher suite being +resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC +saves additional transport and application state in a 0-RTT session ticket, and +imposes additional restrictions on when a server may accept early data. The TLS +stack needs to check with the QUIC stack whether this saved state is valid for +accepting early data. + +One example of such state that the QUIC stack checks when deciding whether or +not to accept early data is the transport parameters extension. When HTTP/3 I removed the mention of transport parameters specifically here, and rewrote this paragraph. My intention is to be vague so someone modifying a TLS stack to support QUIC doesn't say "let me check that transport params are compatible in the TLS stack, and then I'm done and don't need to provide a way for QUIC to reject early data", and instead actually delegates this decision to QUIC. -- 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/2947#discussion_r315394170
- [quicwg/base-drafts] Describe interaction between… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… David Schinazi
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… David Schinazi
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Mike Bishop
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Martin Thomson
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Martin Thomson
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Martin Thomson
- Re: [quicwg/base-drafts] Describe interaction bet… Marten Seemann
- Re: [quicwg/base-drafts] Describe interaction bet… Kazuho Oku
- Re: [quicwg/base-drafts] Describe interaction bet… Christian Huitema
- Re: [quicwg/base-drafts] Describe interaction bet… MikkelFJ
- Re: [quicwg/base-drafts] Describe interaction bet… Martin Thomson
- Re: [quicwg/base-drafts] Describe interaction bet… MikkelFJ
- Re: [quicwg/base-drafts] Describe interaction bet… Jana Iyengar
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Martin Thomson
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Nick Harper
- Re: [quicwg/base-drafts] Describe interaction bet… Mike Bishop
- Re: [quicwg/base-drafts] Describe interaction bet… Martin Thomson