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 protected]> wrote: > (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. > > On 6 March 2017 at 11:17, Martin Thomson <[email protected]> wrote: > > 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. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
