On Thu, Jul 26, 2018 at 11:00:21AM +0200, Marcus Brinkmann wrote:
The new wording for the AEAD chunk size makes it logically impossible to
write a conforming implementation that guarantees to never output or
process unauthenticated plaintext. This is a serious security concern,
which is addressed by state of the art standards like TLS 1.3, and for
which there was rough consensus on this list.
Here is the reason that it is impossible for conforming implementations
to always be secure:
* The draft requires implementations to support chunks up to 4 Exibyte
("An implementation MUST support chunk size octets with values from 0 to
56").
* It is impossible to buffer 4 Exbyte on any device or system that is
not planet-scale.
Thus, any conforming implementation must have a chunk size that must be
supported for which it can not buffer the whole chunk. For that chunk
size, the implementation must either abort (resulting in non-conforming
behaviour) or output unauthenticated data (resulting in non-secure
behaviour).
This is in stark contrast to the original proposal, which had valid
chunk sizes between 64 Byte and 64 KiB, all of which can be supported
securely on a wide range of devices. Multiple people expressed support
for that approach.
I agree that we should lower this. I happen to think the overhead
involved in 64 KiB chunks isn't that significant, but if that's a
concern, we could raise it to 1 MiB. I'd like to point out, though,
that I suggested a smaller chunk size because that's what TLS has
traditionally done: most TLS implementations don't allow the full 16 MiB
chunk size for DoS reasons.
Even if we do allow large chunk sizes, I expect most implementations
will limit them for security and DoS reasons, in which case we'll end up
with the same effective behavior, but poorer interoperability.
On almost any reasonable system with AES acceleration, encryption
throughput is faster than disk or gigabit network, so I hardly think the
encryption overhead is painful here, even for smaller ARM systems.
--
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