Hi,
a lot that Tobias is bringing up here resonates with me, I feel like we should
be thinking more about the fully vs partially authenticated use cases, not just
chunking on its own.
(As an aside, I'm not convinced the early integrity check should have much
bearing on this discussion. Transmission errors are (and should be) handled on
other layers in mostly all cases, and noticing errors earlier than at the end of
data that was going to be buffered anyways is not that big of a gain. In cases
where this is a concern (like uh, tape drives?), a tool should be used that is
actually meant for the job, e.g. par2)
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.
While following the discussion I've gone back and forth a couple of times
between favoring the case for fully authenticated plaintext, or for supporting
streamed workflows with fixed-size chunks (while sacrificing truncation). Both
seem equally valid to me. 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'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.
- V
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp