On Sat, Jun 30, 2018 at 06:00:40PM +0200, Marcus Brinkmann wrote:
Hi,
RFC4880bis contains this segment:
The chunk size octet specifies the size of chunks using the following
formula (in C), where c is the chunk size octet:
chunk_size = ((uint64_t)1 << (c + 6))
An implementation MUST support chunk size octets with values from 0
to 56. Chunk size octets with other values are reserved for future
extensions.
This allows chunk size up to 2^(6+56) = 4 EiB. It is impossible to
implement AEAD correctly with chunk sizes larger than can be buffered in
RAM. A large chunk size would require output of unverified plaintext,
enabling attacks like EFAIL but also others.
I agree with this. The original specification I submitted limited the
value to something smaller for this reason.
To implement AEAD correctly, chunk size must be limited to reasonable
sizes. TLS uses a chunk size up to 2^14 (16 KiB), but any reasonable
limit will do, for example 64 KiB. I suggest to change the text to this:
The chunk size octet specifies the size of chunks using the following
formula (in C), where c is the chunk size octet:
chunk_size = ((uint64_t)1 << c)
An implementation MUST support chunk size octets with values from 0
to 16. Chunk size octets with other values are reserved for future
extensions.
The reason I specified a lower bound of 64 bytes per chunk is that it
doesn't make sense to have chunks that are, for example, 1 byte long.
That's a great way to be wasteful and potentially DoS a recipient, since
each AEAD chunk involves some block cipher overhead.
Of course, trailing chunks may be smaller, and that's okay; the document
anticipates that.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp