Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

David Benjamin <> Fri, 07 October 2016 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2893128E19 for <>; Fri, 7 Oct 2016 15:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.995
X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 Rmak-knmBbZZ for <>; Fri, 7 Oct 2016 15:06:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1D31129431 for <>; Fri, 7 Oct 2016 15:06:46 -0700 (PDT)
Received: by with SMTP id z65so20496282itc.0 for <>; Fri, 07 Oct 2016 15:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=czwPt+bakc0o3rv2CTWt6C9vyA8eelgF6NWq1w9y4SI=; b=FN8gpu4oDm8hLDmSu4WH0UMsLEK7saK6c3Bh11SKCVXa3RPB1TjSbdf9ANCt6CgPLu uUdea8jp4+Jgu9nd110FeytGjp/LcL3NjCrmzdoPKT/N/6CdPjsItPV7AiC+yTG8GfOs P77HtOReyQKmoz5I5H9Qqo1yDMXjhCjR2+EEU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=czwPt+bakc0o3rv2CTWt6C9vyA8eelgF6NWq1w9y4SI=; b=YhhD2SRInbvNcooEYn5OdHtIZCUBwU6p08T/HdSwrPDOotTzjvPMNu0YyXMiR6YttO Jr1a7BbOS+LQTIS/8cHGFoDZpv9Oby1sv9onGLAldEubQWAGa5AWp//+7QSY8FsN1QAv 8nTGPS1MMCMHCuWGPUsqv/wZaw1bob1z7jOJN0UtJxKEPwTVSB+hI+oHJdblYCtF1o8a yX1p/fldfnUIEQPlyNEUF/H1do5EJ1dK0tOhC4A+0eo1kM3/mtm4o/xcXAS2MJdeHh/k NGWY6V2IThB2JN8NZVZb9fcW9mij0KGLFFMh69+v7Bmh87fnUxtAuhMpUyy/np9tgj2K 3qLw==
X-Gm-Message-State: AA6/9Rl7nbLf2452qymzM+xjzieSrUVLMFMzzJQVqn1T57V5AeHlq5LQtBScPefIT4jmDji7Q/Q2JAnFKU/vQnL9
X-Received: by with SMTP id 9mr931122itg.24.1475878005715; Fri, 07 Oct 2016 15:06:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 07 Oct 2016 22:06:35 +0000
Message-ID: <>
To: Benjamin Kaduk <>, Filippo Valsorda <>,
Content-Type: multipart/alternative; boundary="001a11446af84386fc053e4da058"
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 22:06:49 -0000

We were also expecting to want to bound how much traffic a server could be
compelled to skip over without making progress. It actually didn't occur to
me we could let the client know the bounds, rather than just making up a
conservative bound (there's only so much data you can get into an RTT) and
hoping nothing breaks. That's a good idea.

Units is a little interesting. For those purposes, this limit would kick in
whether or not the early data could be decrypted, so the server-side limit
would be measured in ciphertext, possibly even including record headers.
(Although any inaccuracies in converting could be done by just advertising
an underestimate and breaking peers that send pathologically silly things
like all one-byte records. So it doesn't matter much.)

On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk <> wrote:

On 10/07/2016 11:57 AM, Filippo Valsorda wrote:


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.

I think the concern is that a well-meaning client may not necessarily do a
retry here and instead read this even as a network error. And if it did,
the next attempt, if there is still a 0-RTT-able ticket available, may hit
this again anyway...

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

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 listTLS@ietf.org

TLS mailing list