Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

Benjamin Kaduk <bkaduk@akamai.com> Fri, 07 October 2016 21:45 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815CE129459 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 14:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 H9hcrzN5fYzx for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 14:45:33 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BCDFB12943F for <tls@ietf.org>; Fri, 7 Oct 2016 14:45:32 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D5E8E43347D; Fri, 7 Oct 2016 21:45:31 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4B404433455; Fri, 7 Oct 2016 21:45:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; 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 [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 07FD81FC8E; Fri, 7 Oct 2016 21:45:30 +0000 (GMT)
To: Filippo Valsorda <ml@filippo.io>, tls@ietf.org
References: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com>
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: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com>
Content-Type: multipart/alternative; boundary="------------742B4CA1488D1CBB3358AEED"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AkDzPDwsQoJ8vjvhtnSDRYUr6DU>
Cc: filippo@cloudflare.com, aaspring@umich.edu
Subject: Re: [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 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
github.

-Ben

> https://github.com/tlswg/tls13-spec/pull/674
>
> [Please keep me in the CC of replies]
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls