Re: [quicwg/base-drafts] Allow most frames in 0-RTT (#2355)

Martin Thomson <> Thu, 07 March 2019 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E01301311A6 for <>; Thu, 7 Mar 2019 13:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.001 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_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 tobdQ1snxueq for <>; Thu, 7 Mar 2019 13:36: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 E7FF113119C for <>; Thu, 7 Mar 2019 13:36: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=Xdavg2ukRkNvcBM5ucK08R0CkLU=; b=GkoeoN0pxUILXnuC bxXx9FlztAQxWyX3/MHDb8aXJ2TP0JhXxImBcTNRSZQz97C+NP8zb5lr2SYJ+isT vf/aLJmUHh9uA4YGXVjAImJZmnjOG+FWg+XhIbRtZ8A30ZEWpLZcFuIxdUxvf9Ti 0AMpEfbKUQtP+ZZq/3FgP+QxO2c=
Received: by with SMTP id filter0942p1las1-10296-5C818EE1-2D 2019-03-07 21:36:33.459911348 +0000 UTC m=+73973.669975748
Received: from (unknown []) by (SG) with ESMTP id TQwmIwJXTG2RR1zov9HNPA for <>; Thu, 07 Mar 2019 21:36:33.406 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 51F05A8028A for <>; Thu, 7 Mar 2019 13:36:33 -0800 (PST)
Date: Thu, 07 Mar 2019 21:36:33 +0000 (UTC)
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2355/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Allow most frames in 0-RTT (#2355)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c818ee14fe35_691b3fcfe82d45b8121868"; 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: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2PyQs9KyKLaiTwvlGl0AGjgviSwAwth1sV+G Wwzc5t/gUs4Av15nIKiuKciasGiZ1Drz3mHxKQHmqT3hpiO0XvaIFDmcFINW1cH/+H2Efb9gXFYOtN TfMvu1mG4HttGqaPdNLp0q4SRXi0ZZCQkBeu16AsWijfL2lVeNekq1ckWmoSGqmkAUvxcfGOILEGw8 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: Thu, 07 Mar 2019 21:36:37 -0000

martinthomson commented on this pull request.

> +Processing of QUIC frames is idempotent and cannot result in invalid connection
+states if frames are replayed, reordered or lost.  QUIC connections do not
+produce effects that last beyond the lifetime of the connection, except for
+those produced by the application protocol that QUIC serves.
+: TLS session tickets and address validation tokens are used to carry QUIC
+  configuration information between connections.  These MUST NOT be used to
+  carry application state.  The potential for reuse of these tokens means that
+  they require stronger protections against replay.
+A server that accepts 0-RTT on a connection incurs a higher cost than accepting
+a connection without 0-RTT.  This includes higher processing and computation
+costs.  Servers need to consider the probability of replay and all associated
+costs when accepting 0-RTT.

Your point being that a client can keep their costs low?  That's not relevant here.  What matters is what the server spends relative to other connections.

Keep in mind that a client can replay a ClientHello to a server and have it do the work of connection establishment (which is considerable in terms of computation).  The delta for 0-RTT is all the processing that might be triggered by the replayed 0-RTT packets, which might mean buffering or application-level actions.  If that work is significant, and it could be, then you have an exposure.  Add the relatively negligible work of accepting packets and decrypting them if you must.

In terms of outright expense to a server, it is entirely possible that spamming bogus ClientHello messages (which don't even need valid key shares, possibly not even valid anything) could more effective than spamming 0-RTT.

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