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?
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp