Re: [openpgp] AEAD Chunk Size

["Neal H. Walfield" <[e-mail]>]

On Mon, 18 Mar 2019 13:23:07 +0100,
Vincent Breitmoser wrote:
> Ideally, a receiver won't ever output unauthenticated plaintext, hence ideally
> all of the chunking discussions would be moot. What chunking brings to the table
> is to give the *sender* of a message the option to *allow* the *receiver* to
> emit partially authenticated plaintext, trading a truncation vulnerability for
> the ability to process data on a smaller buffer size than the entire plaintext.
> This is useful for $large amounts of data, or streamed workflows with unknown
> data sizes.

When using chunking correctly, the emitted plaintext is not partially
authenticated; it is fully authenticated: all of the bytes are right.
As such, I'd prefer to use the term "authenticated prefix" in place of
"partially authenticated plaintext".


Some questions that come to mind:

  - Should an implementation ever be allowed to emit unauthenticated
    plaintext?

    Is it okay to have a --do-it-anyway flag?  How to we prevent
    implementors from doing it anyways?


  - What should an implementation do if it is passed a large message
    (say n times the available RAM) and chunking is disabled?

    Should implementations be smart enough to detect that they can't
    process this apriori?  Should they wait for the OOM-killer?
    Should they panic?  High-level languages don't make it easy to
    recover from memory allocation failures.  For instance on Rust, an
    out of memory error results in a panic.  It would be a shame if
    the application crashed, or the sender could DoS the receiver.

It seems to me, if we are going to handle the complexity of chunking,
then we should just embrace it, and not make it even more complex.  If
an application wants to protect itself against truncation attacks,
then it can buffer the output, or the openpgp implementation can have
a flag.

> However, I can't see a good use case for variable size
> chunking: it adds complexity to spec and implementations in particular on the
> receiving side, and pushes the onus on reasoning about chunk sizes to the
> implementations, which is basically impossible in the face of interoperability
> concerns.

I fully agree with this.

> I'd like to bring up a new proposal then: Support either no chunking, or
> fixed-size chunking. The advantage would be that the sender's position on
> authentication is made more explicit: If they don't do chunking, they expect the
> receiver to fully buffer and authenticate before processing, which could
> currently only be achieved implicitly via a large chunk size. If they use the
> fixed-size chunking, they explicitly offer the option to emit partially
> authenticated plaintext.

I'm concerned about an attacker's ability to twiddle the chunking bit.
Do you have any thoughts on how to prevent this?