Re: [TLS] Application Data payload

[David Benjamin <[e-mail]>]

On Mon, Mar 6, 2017 at 5:52 PM Martin Thomson <[e-mail]>
wrote:

> On 7 March 2017 at 08:43, David Benjamin <[e-mail]> 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
much.

David