IETF Logo Mail Archive

Re: [quicwg/base-drafts] It is unclear if some frames are forbidden in 0-RTT (#3430)

Mike Bishop <notifications@github.com> Thu, 06 February 2020 10:45 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 8CC98120273 for <quic-issues@ietfa.amsl.com>; Thu, 6 Feb 2020 02:45:14 -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 FgYlhENOlMZH for <quic-issues@ietfa.amsl.com>; Thu, 6 Feb 2020 02:45:11 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81F5120271 for <quic-issues@ietf.org>; Thu, 6 Feb 2020 02:45:11 -0800 (PST)
Received: from github-lowworker-943b171.ac4-iad.github.net (github-lowworker-943b171.ac4-iad.github.net [10.52.22.59]) by smtp.github.com (Postfix) with ESMTP id 1CA936A0D01 for <quic-issues@ietf.org>; Thu, 6 Feb 2020 02:45:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1580985911; bh=SPzRpNjxKtrjNBYWhDObYWThOZ5eOJOgcDGstWEKDZU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oqhOt2j3Vsw3+zRmJ3vV43hTJR/1zM8bVNnQS8OzPfHzBVwqZt0/BoKw4FzBsKyfU lDymYJPFCs45XfW7elAQmpw3OEvxYGm0WBzBji82C3xnZ4rlju2mN3SZmadIH3V6+5 qA1tqIXY0DBvoJvp3MIe+DF48l1pLCROatIrUv1E=
Date: Thu, 06 Feb 2020 02:45:11 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7V6PTVPQRWBKLQKZF4JEQLPEVBNHHCC3RXUI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3430/582844237@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3430@github.com>
References: <quicwg/base-drafts/issues/3430@github.com>
Subject: Re: [quicwg/base-drafts] It is unclear if some frames are forbidden in 0-RTT (#3430)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e3bee37e78a_16073f998decd964139692"; 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/5kVXHEvRDfcbhQp3hdtH4rfjKCo>
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, 06 Feb 2020 10:45:14 -0000

It's not forbidden, it's impossible -- or more precisely, it's a protocol violation to send them for other reasons.  HANDSHAKE_DONE and NEW_TOKEN frames are sent only by servers, and servers don't send 0-RTT.  A client sending them at any time is forbidden.

PATH_RESPONSE is sent only in response to a PATH_CHALLENGE; PATH_CHALLENGE can only be sent in 0-RTT or 1-RTT, and servers don't send 0-RTT.  Therefore, the client can't be responding to a PATH_CHALLENGE while it's still sending 0-RTT.

RETIRE_CONNECTION_ID can't retire the CID of its own packet.  Until the transport parameters have been parsed, the client only has one CID for the server, so it's illegal to retire it.  Once the transport parameters have been parsed, in the "simple" handshake flow, the client shouldn't be sending 0-RTT.  If the handshake requires an extra round-trip, is it possible to keep sending 0-RTT after having processed the Server Hello?

-- 
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/3430#issuecomment-582844237

v2.23.0 | Report a Bug | By Email