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

From: Peter Beverloo <[email-masked]>
Date: Wed, 27 Jan 2016 18:47:21 +0000

Hi Martin, others,

I have some comments in regards to draft-thomson-http-encryption.

Firstly, each record currently includes between 1 and 256 bytes of padding,
while the default record size is set to 4096 bytes. This is in many cases
not
sufficient, for example in the pad-to-next-power-of-two case.

I've proposed a pull request to change the padding size to two bytes.
  https://github.com/martinthomson/http-encryption/pull/7

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.

Of course, introducing a fixed record size would violate the requirement
set by
draft-ietf-webpush-encryption of only allowing a single record, for any
message
that is larger than said size. A reasonably clean way of addressing this
would
be to separate the Content-Encoding values: aesgcm128 vs.
aes128gcm-streaming.

As a slight meta question, what are the expected users of the streaming
model?

Thanks,
Peter

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 11:47:30 +1100

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

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

---

From: Peter Beverloo <[email-masked]>
Date: Thu, 28 Jan 2016 12:49:03 +0000

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

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

> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Jan 2016 08:56:35 +1100

> be derived from the content's length. This seems sub-optimal.

I assume that you are talking about push again.  I figured that since
we aren't guaranteeing that messages larger than 4k are delivered,
this would be an uncommon scenario.   >4k is pretty sub-optimal for
push for other reasons too.