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

On Thu, Jan 28, 2016 at 12:47 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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

While many cases could be covered programmatically, this isn't true for
all of them (e.g. a message having a uint8 padding length of zero, with
the payload starting with \x00 as well).

Changing the aesgcm128 Content-Encoding to aesgcm would work. When
considering use of AEAD_AES_256_GCM in the future, it could be named
aesgcm256 to distinguish between the two AEADs.

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

Thank you for the clarification. I've further read up on the usage of
record sizes in TLS, and the performance implications of them.

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

I am less concerned about constraints to the acceptable range. The current
sole user of http-encryption, webpush-encryption, does not benefit from
the streaming model and mandates that the record size must be equal to or
larger than the payload.

For records larger than the default of 4K, this means that implementations
will have to specify their length in the Encryption header while it can
be derived from the content's length. This seems sub-optimal.

Thanks,
Peter

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