On Mon, Mar 18, 2019 at 01:23:07PM +0100, Vincent Breitmoser wrote:
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.
Not rejecting your idea outright, just curious how it would work with
e.g. instant messengers where there is streaming of irregularly-sized
packets coming at irregular intervals (and the users would expect that
Things Just Work(tm) for both two-character messages and five-megabyte
files sent over the wire).
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org}
pp(_at_)storpool(_dot_)com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp