[TLS] Add max_early_data_size to TicketEarlyDataInfo

Filippo Valsorda <ml@filippo.io> Fri, 07 October 2016 16:57 UTC

Return-Path: <ml@filippo.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5928F1295EF for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 09:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=filippo.io header.b=E5NXjMNf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=cXmt4n+J
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FXbLUNeCa0ZY for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 09:57:38 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D635B1295F0 for <tls@ietf.org>; Fri, 7 Oct 2016 09:57:38 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 340DC20866; Fri, 7 Oct 2016 12:57:38 -0400 (EDT)
Received: from web5 ([]) by compute3.internal (MEProxy); Fri, 07 Oct 2016 12:57:38 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=filippo.io; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Is8 83vNLqSF8uNEllOaCbr9NyMI=; b=E5NXjMNfbXGyBUawUM8MM8hmjydKOH+QYpQ PZ9d53fA75U/NM1YFMG4ecXCHrBW116e8apUGEoHEj6xqruk1hBUlcG922bu270X 8F093jpmoF2yyT6/01HqHUUVxq0oBm13pqhq29C0asi/57vZX/g9FN/MgdwIQLCP OlnRH2BA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Is883vNLqSF8uNEllOaCbr9NyMI=; b=cXmt4 n+J1newMl/UrgwN8tBf5yHf8lIcVxYtyUIt0S/JWpRyO0To1vDxUz7QmJ3rv1NQU XOp0XDb9eGAnpw2DVGIusuSAWyd6N3oNDOeFO04tomXngIbTx9X2eTbFsbcyS3li 4f0vzLW6yFB611GT8+0i10vdA3xgDsY2bngD9s=
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 08CEC96E99; Fri, 7 Oct 2016 12:57:37 -0400 (EDT)
Message-Id: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com>
X-Sasl-Enc: ESAAJp2pVB1AaiR4u5lwzwgzZJCsDzL32N4H3uW4NysM 1475859457
From: Filippo Valsorda <ml@filippo.io>
To: tls@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Mailer: MessagingEngine.com Webmail Interface - ajax-43d69252
Date: Fri, 07 Oct 2016 12:57:37 -0400
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xNWUI84UrubtDMRPzemi9sGhsp0>
Cc: filippo@cloudflare.com, aaspring@umich.edu
Subject: [TLS] Add max_early_data_size to TicketEarlyDataInfo
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2016 16:57:40 -0000


Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a
client sent early data, there's no way to accept only a part of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed


[Please keep me in the CC of replies]