Re: [TLS] Application Data payload

David Benjamin <> Mon, 06 March 2017 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41334129A6F for <>; Mon, 6 Mar 2017 15:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 FWHxvyOu_L39 for <>; Mon, 6 Mar 2017 15:06:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D5EA12896F for <>; Mon, 6 Mar 2017 15:06:54 -0800 (PST)
Received: by with SMTP id 25so71417013pgy.0 for <>; Mon, 06 Mar 2017 15:06:54 -0800 (PST)
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=1woRfZVD46OtiKQy++UdEZjheF062hgbUIcwz+/FK2o=; b=OMh2wsaTTG8dqenbmUvhceWvDsGB+o2JjoHkB1oduOve9MgSrjvf2uRYXXKmFfoKVa JtTvIbPLnc+YXQmd1GnMfyq58n9rs8HkXbWJWhm/erozm5uofeaOdzPXbode1rt9ViJc q62Ca2TnSD2EGY4zdvSLVZpikXkO6uaorUxBk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1woRfZVD46OtiKQy++UdEZjheF062hgbUIcwz+/FK2o=; b=MNOmwGnhkljGr4/Xet6b8DwMQRnPp3XugLawcsFqsJteo4Z9OCqLmJWXnpjPv5ptMa v1AMgPGI8RQK8qkR7ZzNyVKbs7OBBeN8ZEQx2xg0nC7bNxs2J/Qg+6J0uC/c6iAW1yJc u+2kgfAr7oRNVf8fUe0HwDh7jBdgfADxVF0GooXTIWGdhRngj08jvcYWZdBz87PdUtfV 9+pdSt9BDFZFkLqjk1kT1FyEe8FfIGD7FoYU9vutyUf/oppklhG2hmyGdc/c9+Poi+hq L5SG6SuUYXcnK6BwMIm1UhYx8m5Ln+dxUkScgwPojCp2Tri2PYrZJ9hqNoL90ZskKMQi MJew==
X-Gm-Message-State: AMke39m20cPXid2e/680irIcETFJ4+yMP1ZlPsEEnu7GVCGmC6g1tCbw0svhgSgG2hJzOsfowa9C1ykGIr6MygWE
X-Received: by with SMTP id t3mr24136635pgt.162.1488841613901; Mon, 06 Mar 2017 15:06:53 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 06 Mar 2017 23:06:43 +0000
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="94eb2c114a02867050054a17f345"
Archived-At: <>
Cc: Filippo Valsorda <>, "" <>
Subject: Re: [TLS] Application Data payload
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: Mon, 06 Mar 2017 23:06:59 -0000

On Mon, Mar 6, 2017 at 5:52 PM Martin Thomson <>

> On 7 March 2017 at 08:43, David Benjamin <> wrote:
> > To clarify, our interpretation of the spec was that it is the encrypted
> > data, not unencrypted data.
> Well, clearly we disagree.  To be clear, I don't mind much if it's the
> encrypted data, though we'd need to also agree if the count included
> the authentication tag (yes, probably) and the record header (I don't
> know).
> You appear to be conflating two things:
> 1. The amount of data that a server might have to hold on to when it
> accepts 0-RTT.  The original reason Filippo suggested this feature was
> so that it would be possible for their servers to hold 0-RTT data
> until the handshake was complete.
> 2. Records that do nothing other than waste server time.  Into this
> category we can place records with only padding or very little actual
> data, extra key updates, CertificateRequest, and - the one you
> highlight here - early data that is ignored.
> My interpretation was that the first the only thing that needed tight
> bounds, the second could be quite fuzzy and could come down to things
> like current server load and DoS mitigation strategies.
> We really need to agree on the right answer here.

I think we are in agreement and failing to communicate due to the poor
choice of terminology. Partway through the thread the interpretation of
"encrypted data" switched from "data to be encrypted" to "data that is
encrypted". (You first objected that "unencrypted data" matches what
BoringSSL implements and now that "encrypted data" matches.)

Let's try this again:

As the spec is written right now, our interpretation is that
max_early_data_size counts the plaintext application data, not including
any encryption and record-level overhead. This aligns with (1).

Separately, we bound how much data on the wire we will skip over. This is
(2). These are not the same units, so we intend to advertise a smaller
number as a fuzzy estimate and don't anticipate the fuzziness mattering