Subject: [TLS] Application Data payload

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Mar 2017 11:17:59 +1100

The section on the maximum early data size says this:

"Only Application Data payload is counted."

I don't know how to interpret that.  I can see arguments for counting
TLSInnerPlaintext.content or all of TLSInnerPlaintext.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Mar 2017 17:06:18 +1100

(Adding Filippo, who wrote the original change.)

I just did some spelunking of the archives, and poking at boring SSL.
I found that David Benjamin mentions unencrypted data, which seems to
be consistent with what boring implements:

<https://mailarchive.ietf.org/arch/msg/tls/b5GpGR9QQpBV3tbxCspdHVJs8HU>

I don't think that this makes sense: the true cost to the server is in
the data it has to store, not process (a client has many better
options for causing the server to expend CPU resources).  Any data
that can be ignored is cheap.

---

From: David Benjamin <[email-masked]>
Date: Mon, 06 Mar 2017 21:43:17 +0000

To clarify, our interpretation of the spec was that it is the encrypted
data, not unencrypted data.

Separately, we limit unencrypted data that we skip over, as I mentioned in
that thread. These are not the same units as max_early_data_size are
currently specified, so we intend to advertise a smaller value in the
ticket to compensate for this difference.

David

On Mon, Mar 6, 2017 at 1:06 AM Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Mar 2017 09:52:37 +1100

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

---

From: David Benjamin <[email-masked]>
Date: Mon, 06 Mar 2017 23:06:43 +0000

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

David

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Mar 2017 10:12:05 +1100

On 7 March 2017 at 10:06, David Benjamin <[email-masked]> wrote:
> max_early_data_size counts the plaintext application data, not including any
> encryption and record-level overhead. This aligns with (1).
>

Ahh, OK, that happens.  I will write a PR to clarify this.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Mar 2017 16:30:39 -0800

https://github.com/tlswg/tls13-spec/commit/2c72e1faa76c3be06e202d1181cf9c0959dea336

On Mon, Mar 6, 2017 at 3:12 PM, Martin Thomson <[email-masked]>
wrote:

> any