Re: Padding and record sizes in draft-thomson-http-encryption

On 28 January 2016 at 05:47, Peter Beverloo <beverloo@google.com> wrote:
> I've proposed a pull request to change the padding size to two bytes.
>   https://github.com/martinthomson/http-encryption/pull/7

Thanks for doing that Peter.  I think that this is a good change.  The
only concern I have (a self-serving one) is how we might cleanly
distinguish between the current form and the new one.  Maybe we can
drop the "128" from the C-E name at the same time.

> The draft defines a streaming model having a sender-configurable record
> size.
> What is the motivation for allowing this by default? TLS defines 16KB
> records
> and only allows negotiation of this value per an extension.

The motivation was a tiny bit of caution.  We know from experience
that record sizes have a material impact on performance.  Short
records are good for latency, but long records are good for throughput
and reduced overhead.

Note that the TLS analogy isn't perfect.  The 16KB thing is a maximum
[16].  TLS implementations can (and frequently do) send much smaller
record sizes to improve latency.  In comparison, the content encoding
has a fixed record size.  That allows for random access and less per
record overhead but it does reduce flexibility.

The rs parameter aims to retain at least a little of that flexibility.
Big resources with lax latency constraints can use big records up to
the limits permitted by the cipher: 2^36 - 31.  Resources that need
good responsiveness (like html pages) can use tiny record sizes.

I didn't think it necessary to constrain the range, but if someone
wants to propose that, I'd have to concede that it's probably not
useful to have rs=2 or rs=2^35.  I just didn't want to be the one to
choose where the line is drawn.

[16] That limit might jump to 64K in TLS 1.3: discussed a little but
not seriously proposed.

Received on Thursday, 28 January 2016 00:47:58 UTC