Re: Consensus Call on #2344: Frames that are allowed in 0-RTT packets

"Martin Thomson" <mt@lowentropy.net> Thu, 07 March 2019 01:39 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3161312C4 for <quic@ietfa.amsl.com>; Wed, 6 Mar 2019 17:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=rKLWEvgJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=smtAFA6H
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 YhdL96B-lat0 for <quic@ietfa.amsl.com>; Wed, 6 Mar 2019 17:39:57 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24901312BD for <quic@ietf.org>; Wed, 6 Mar 2019 17:39:56 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 56A0E2125E for <quic@ietf.org>; Wed, 6 Mar 2019 20:39:56 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 06 Mar 2019 20:39:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type:content-transfer-encoding; s=fm1; bh=vnty4jSAs/Wiq OjGOXq+fX6OGD9BXnrt0w/fg3D7MrY=; b=rKLWEvgJzp3nrTOGdvqWS8Jnifnl0 7ui6sG71rkYdNM82mrQtZA+t0HzxyuiyvNG1QKW9tQLIdxjCJ05qLvYm5VEzHBjC Koo03MUszdf2UX1subn8wPC+B6G15nyXkSq48YMTCpVjg2pq3si9nYQL8bwpbo+7 0fGq1QMMXKGNMlqSFJl7pfRRJl0//DlovG/SZWf/9ft2Tx6Vo+kWnm7IP9kUJs8F +131tnSbTJBBO4DAcJhNc4gQdNNM14B7S7F6oeK842jCRC0BzlJHfdYx+le4RpEi j0l43VmxlmoivrTrK3sLDFKJSr5sgdSqbnXgqdBpn552OgC3n72rNqrpQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=vnty4jSAs/WiqOjGOXq+fX6OGD9BXnrt0w/fg3D7MrY=; b=smtAFA6H 02Y8mlHcnYRObdpco96X3RoeWzf1ZvmD4m0udxgJueqMxKEwOub8fqDPM/DmSJvs hTxk+gXJiwBmknZnHUJpLqjaKHy0DETxzUh3CEcO2qoyY0fQB3Tz77Sy5B22lhkj fSIFEBWfewccBLp2czOgXvGYKf1dR7ntW8SNY0K8mAvwT3jZ4c+2NcgPygpSNDvr cHFbOeKzmdKAsTIjEZyuD0Q/XVm6/27OL5Bhy3fZQSt8/nignYZmMvnOoKchzyqL T9mlRp/wTmXeESVw5ELPgReX4VYpak1+SuSryPdHBMk5mqb/HewGn4+V4fV3uNqA JG9ertOpQ8pYhg==
X-ME-Sender: <xms:a3aAXKpWNOXedyAu0BKmq6Dsc3PvC8kyK3B2BtyQDWV1xOVMhyZnwQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeejgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:a3aAXIOMmNLtN9asErkGWht1RJ3zUAzLxOXsQfLHDpm0wHvEu2uGNA> <xmx:a3aAXIkJQVj5rGuR_yZzzDzHyVlRTRzo2h6fjoVeL7zYccsKdJqwgQ> <xmx:a3aAXCuN88bx4FDUSa8U7c9TT1cPOD36GSIwrcjhr6lvlLxMs4R2Hw> <xmx:bHaAXBL25L-Lsd3NoYL_b5h6sy9MCUPORltO_V0ygx3U9mlbS_CH_w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE9447C1EB; Wed, 6 Mar 2019 20:39:55 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5
X-Me-Personality: 92534000
Message-Id: <de598ef3-f653-40ac-a1b8-62931b6ff7ca@www.fastmail.com>
In-Reply-To: <CAN1APdcBdnjKV9cMPMcpz2EQKz8r=nJwpKhp_Bd-KSVmz7ZB4Q@mail.gmail.com>
References: <638A4210-C98A-47C5-B65C-4CE65FEB3C90@mnot.net> <DB6PR10MB17666DB413F540D90DB5B716AC730@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <f9de802c-a0b0-4f03-a7ec-a39149e9b28b@www.fastmail.com> <CAN1APdcBdnjKV9cMPMcpz2EQKz8r=nJwpKhp_Bd-KSVmz7ZB4Q@mail.gmail.com>
Date: Wed, 06 Mar 2019 20:39:56 -0500
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Consensus Call on #2344: Frames that are allowed in 0-RTT packets
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TqwdyXOmIKO51FWuc2sPOEv3Jjc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 01:39:59 -0000

Hi Mikkel,

Thanks for writing this up.  This was a great help.

I've made some changes based on this.  It maybe isn't as short as you would like, but I think it is better for the attempt.

On Thu, Mar 7, 2019, at 11:03, Mikkel Fahnøe Jørgensen wrote:
[Snip shared text]
> The QUIC transport protocol is not vulnerable to replay attacks and does
> tolerate replayed frames because all frames are idempotent and because
> no state is carried across connections.

Your own comment here suggested that we point out the exception to this, which is the 0-RTT session ticket and the connection state.  If this said "no application state is carried across connections", that might be more accurate.

This also removes my text that qualifies this by saying that only the frames defined in -transport have this property.  That's probably not critical, but it is more precise.

> Applications might carry state across connections and can be confused by
> STREAM frame content under 0-RTT keys and also by other content such as
> flow control credits. Servers can be configured to reject old 0-RTT
> packets but it is not perfect nor guarenteed. Only application protocols
> can define semantics that are acceptable for 0-RTT sessions, if any.

I don't understand what you are trying to say here.  There seem to be several ideas:

* Confusion about STREAM frame content: The main 0-RTT hazard is not about confusion, but about the effects resulting from doing the same work twice.

* Flow control credits: I don't believe there is any concern about flow control other than the one Kazuho articulated: the need to buffer an arbitrary amount of 0-RTT data in the case where 0-RTT was accepted.  I don't think that needs discussion here because we have good mechanisms in place for constraining that (aside from just dropping 0-RTT packets when the buffer is full, which was always possible, if suboptimal).

* Rejecting 0-RTT: that's a protection measure described in TLS, so I don't think we need to repeat it.

* Only applications and application protocols can say what is OK in 0-RTT: Yes.  That's the most important message here.  I spent a two whole paragraphs on that.  With a MUST that I think is critical.  I've cut this down to one now.

> A copied 0-RTT session is cheap to establish and can be exploited to
> expend excessive server resources. Applications MUST account for this
> overhead before accepting 0-RTT connections.

This is very terse, but think that it is better than what I had in its general scope.  I would rather concentrate less on "cheap to establish" and more on the fact that accepting 0-RTT on a new connection is inherently much more expensive in terms of computation and state than other types of connection.  Replay protections from TLS do severely limit the scope of attacks.
 
> QUIC extensions SHOULD describe how replay attacks affect their
> operation. Application MUST prohibit extensions where efficient
> replay mitigation strategies cannot be provided.

This is a fine change.

> On 6 March 2019 at 22.38.36, Martin Thomson (mt@lowentropy.net 
> <mailto:mt@lowentropy..net>) wrote:
> 
> > I responded to the suggestion (it got lost in the noise). If you have specific suggestions about what text might be removed, that would be great. 
> > 
> > On Wed, Mar 6, 2019, at 16:39, Mikkel Fahnøe Jørgensen wrote: 
> > > 
> > > There is a pending suggested change on TLS impact on state. I’m fine 
> > > with a negative list in 0-RTT, but would prefer a positive list, 
> > > possibly in a table. I think the discussion on replay could be trimmed 
> > > a bit. 
> > > 
> > > *Fra:* QUIC <quic-bounces@ietf.org> på vegne af Mark Nottingham <mnot@mnot.net> 
> > > *Sendt:* onsdag, marts 6, 2019 4:51 AM 
> > > *Til:* IETF QUIC WG 
> > > *Cc:* Lars Eggert 
> > > *Emne:* Consensus Call on #2344: Frames that are allowed in 0-RTT packets 
> > > Regarding: 
> > > <https://github.com/quicwg/base-drafts/issues/2344> 
> > > 
> > > We discussed this in Tokyo, and then continued discussion on-list.. The 
> > > editors now believe that this PR resolves the issue: 
> > > <https://github.com/quicwg/base-drafts/pull/2355> 
> > > 
> > > ...... and discussion so far seems to support consensus to do so. If 
> > > you object, please do so on the issue or in response to this message; 
> > > absent any pushback, we'll declare consensus at the end of the week. 
> > > 
> > > Regards, 
> > > 
> > > -- 
> > > Mark and Lars, WG Chairs 
> > > 
> >