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

Martin Thomson <> Mon, 21 January 2019 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B5B5129B88 for <>; Mon, 21 Jan 2019 13:46:41 -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 wH_5L0SPW9OL for <>; Mon, 21 Jan 2019 13:46:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F9771200B3 for <>; Mon, 21 Jan 2019 13:46:39 -0800 (PST)
Date: Mon, 21 Jan 2019 13:46:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1548107198; bh=Cdzk/VKcVYoJK5zexwTKs92XAKFEd727vhA3S6P1FM4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bv9ZRbc1qjcv4dDoU/aTWa8Gq8FApRYBeCJnd2+jGNIp3PtWGUPx5HpnFCJf7ThaP RGyxkAVA0S19Yg3YN4UZQWxhhDvfUfWqJwhucZH09y6zpbHRrDKgyj1hPYhNT7/8oI f5vBicT7Yui2mCWNb3soDSew8MVq0WMFt4COuq8o=
From: Martin Thomson <>
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_5c463dbe1afcc_7c3d3faadfed45bc1018479"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Mon, 21 Jan 2019 21:46:42 -0000

Bring the discussion back from #2355.  I'm thinking about @marten-seemann's comment there and I think that it would be easier if we were able to permit any frame type in 0-RTT (except CRYPTO, which has nothing to carry).

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.

There might be some application-level significance to resetting streams in addition to carrying stream data, particularly when you consider the potential for selective replay.  An attacker with sufficient knowledge of the contents of packets could replay some packets and not others to effect changes.  But while the signals that a server application might receive are different, they are not outside of the range of possible signals that a client accepts as possible when sending the 0-RTT.  That is, if the server receives a partial stream rather than a complete stream, that is a potential outcome that the client has to accept as a possibility even when there is no attack.

If there are lasting application-layer effects from a RESET_STREAM (or STOP_SENDING), then this might cause problems.  But the application actively chooses to accept those risks by triggering these actions before the handshake is complete.

In addition, RESET_STREAM is a poor carrier for state-changing action because its semantics are better suited to abandoning state-changing effects, not creating them.  It would be a poor choice in protocol design to carry any application-layer signal with RESET_STREAM that implied a need for some action.  HTTP does this with CONNECT in a way, but that is only to match with a TCP RST and comes with no real expectation of it being reliable.

In the end, I conclude that we should permit all frames in 0-RTT and 1-RTT.  While there is some increased risk here, I think that this is best left to the 0-RTT profile for the protocol that uses QUIC.  For HTTP, where the only application-layer effect RESET_STREAM can have is to cancel requests, the result is to reduce exposure to replay.  Other protocols will need to make their own assessment about safety, but I don't anticipate problems.

I'll adjust #2355 to match.

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