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

Martin Thomson <> Tue, 22 January 2019 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C78B6128AFB for <>; Tue, 22 Jan 2019 11:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Status: No, score=-7.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_NONE=-0.0001, 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 NG4wVx1mAlkZ for <>; Tue, 22 Jan 2019 11:44:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45BA913100D for <>; Tue, 22 Jan 2019 11:44:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=iMTK0cMGNpMtmZ6gAFoOrLHwpPE=; b=CVozrqyUTaTZi5Oi 9ANg2A1XwjFvidTm/OZGEZcDm0MA7b15OmYQYYEa4CeU7FEmyd/5AZ8rZlMAJWRy 2IZdWwS/J/fp9KXqAIO72gyzCBFNrTK94Skpb41AiNlgAwJOY9MhxK0WtCNi4HJW RezgWKq0qd9EfAF66a/Gr+pN9DE=
Received: by with SMTP id filter1554p1mdw1-2108-5C4772A1-6 2019-01-22 19:44:33.232721197 +0000 UTC m=+673765.915604520
Received: from (unknown []) by (SG) with ESMTP id XHHzjLtPSXSGNS-0jk9HYQ for <>; Tue, 22 Jan 2019 19:44:33.192 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 2BC184C0330 for <>; Tue, 22 Jan 2019 11:44:33 -0800 (PST)
Date: Tue, 22 Jan 2019 19:44:33 +0000
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_5c4772a1285b5_72df3f8322cd45bc6689"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1rw1dOFLUCGcZK78CgLgTTevRX/GAndZ6y9I EPmmj3bnjHAGvhUIoAC+yJefnsdXix08sT+/J0cU9zzj0+ey0SJZGo39nDAXwJdozuiW/09Ah387bv KkD28aFzzS6uzcvn+cwlKO7UIhPR7w3JUDbqC9hBZQbK6GZhM8fqpbV8n14xEbS2w8EU70yk/OT+M9 Y=
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 19:44:40 -0000

Is the concern here about a denial of service attack on the server?  That is, the extra frames that it might receive, which aren't really limited in any way by flow control or other such limitations, might cause it to do too much work?

This doesn't sound that interesting to me.  There is always a risk when you accept 0-RTT that the client or data is bad.  As @MikeBishop points out, you shouldn't be accepting the same 0-RTT multiple times.  The recommendations in TLS 1.3 provide some tips on how to avoid that.   But even if your server configuration doesn't allow you to detect that and stop it, the work you expend on 0-RTT packets is a cost that you take on.  And you take on that work with the understanding of the associated risk of replay.  Clients can always send far more stuff than you are prepared to process; servers just need to make the call.  For instance, rejecting 0-RTT would be my first response to increasing server load.

If a client chooses to send 0-RTT when 1-RTT keys are available to it, maybe we can allow servers to cut them off.  That's maybe hard to police, but simple things like exceeding initial flow control might be detectable.  Even if the server has provided more credit, the client should still be operating within the initial window for 0-RTT.

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