Re: [quicwg/base-drafts] RESET_STREAM should be allowed in 0-RTT packets (#2344)

Kazuho Oku <> Tue, 22 January 2019 00:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 644EF130E0A for <>; Mon, 21 Jan 2019 16:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5_dCF3MnLJhS for <>; Mon, 21 Jan 2019 16:40:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7D58130E00 for <>; Mon, 21 Jan 2019 16:40:58 -0800 (PST)
Date: Mon, 21 Jan 2019 16:40:57 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1548117657; bh=409sGXQuNITMFUETK9MTi/vCUyP+JWSwUE+XtxyiG5M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VkmTI5UPXLdUvcjn0psy2lXwfNiKT/WhIqiTMK3K7cuotAGTT8G/V2v5AR8dVz59j wQ8VnrRrTcyeMiff7xi81/IkVnYb+gTgqCRNPj3FL0WFe/kCbYyDLHQSVHJ9TBBIu9 sho51P1gpAS8+gJLhhH5CeJwCrjA0X4NkWAEXsnk=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2344/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] RESET_STREAM should be allowed in 0-RTT packets (#2344)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c4666999642b_679d3ff5f6ad45b8382927"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Jan 2019 00:41:01 -0000

> In thinking about this, the main concern is whether there is any replay risk associated with any of these frames. Going through each, I didn't find anything. Though replay does result in spurious state being created, it's all transient and connection-bound, not application state. In general, all connection-level control messages affect only connection state, which goes away when the connection goes away. And replayed 0-RTT always results in the connection being thrown out as the full handshake cannot successfully complete twice.

The problem with 0-RTT in QUIC is that, unlike TLS 1.3 (that has max_early_data_size), there is no limit in the amount of data that the client can send using the 0-RTT key. IIUC, currently, it's entirely up to the client to decide when it switches from 0-RTT to 1-RTT keys.

As we know, Initial and 0-RTT packets can be replayed against different servers within a server cluster that does not (cannot) implement the use-only-once rule for the session tickets. I am concerned that widening how 0-RTT packets can be used might lead to additional exposure to the attack surface.

An attack would go like this:
1. an attacker creates a legitimate connection and obtains a session ticket
2. the attacker reconnects using the session ticket, and exchanges lots of information with the server (involving MAX_DATA, MAX_STREAMS, etc.). However, the attacker sticks to using 0-RTT for packets it emits, even after the handshake is complete.
3. simultaneously, the attacker creates many QUIC connections using the same Initial packet as that of step 2, and then sends the copied 0-RTT packets. The server will handle those and commit state. Because the client never responds with an 1-RTT ACK, the connection will eventually die. However, a client can create a connection with huge PTO (by delaying Initial packets) to have enough time to let the server accept many packets.

IMO it is preferable to allow less frames in 0-RTT packets, because it narrows the attack vector.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: