Re: [openpgp] Need to publish bis-05

["brian m. carlson" <[e-mail]>]

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