Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

Benjamin Kaduk <> Fri, 07 October 2016 21:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 815CE129459 for <>; Fri, 7 Oct 2016 14:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, 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 H9hcrzN5fYzx for <>; Fri, 7 Oct 2016 14:45:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BCDFB12943F for <>; Fri, 7 Oct 2016 14:45:32 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id D5E8E43347D; Fri, 7 Oct 2016 21:45:31 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 4B404433455; Fri, 7 Oct 2016 21:45:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1475876731; bh=xKzRaw8X3up7SaC6cySEqKqXKsv5BMq45ZmUQTuZZ8Y=; l=4265; h=To:References:Cc:From:Date:In-Reply-To:From; b=PaW2WW7lVqYB+mCq5IXgCp556jEbAMLkDVV8Hy7XSYbW183GlpMjbBHTXcuPTiv+s 45jYGmQnI94jGozgdC7dowb+YKzzI9jNZIEvmC45CkmDHXVN77nyDlan7hteCLouE6 PJjevEKTo29pjp/s4DXmYg/yES+0kMI5kD4WHqm8=
Received: from [] ( []) by (Postfix) with ESMTP id 07FD81FC8E; Fri, 7 Oct 2016 21:45:30 +0000 (GMT)
To: Filippo Valsorda <>,
References: <>
From: Benjamin Kaduk <>
Message-ID: <>
Date: Fri, 7 Oct 2016 16:45:30 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------742B4CA1488D1CBB3358AEED"
Archived-At: <>
Subject: Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Oct 2016 21:45:35 -0000

On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
> Hello,
> 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

Well, "have to" is perhaps a bit of a stretch; the client should be
prepared to cope reasonably if you abort the connection arbitrarily.

> 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
> it.

But this seems like a good idea; I left a couple of ~editorial notes on


> [Please keep me in the CC of replies]
> _______________________________________________
> TLS mailing list