On 07/01/2018 08:53 AM, Peter Gutmann wrote:
Marcus Brinkmann
<marcus.brinkmann=40ruhr-uni-bochum(_dot_)de(_at_)dmarc(_dot_)ietf(_dot_)org>
writes:
If a chunk can not be authenticated, implementations MUST discard the
plaintext without further processing. Unauthenticated plaintext MUST not be
output to other applications or the user.
Unfortunately it's nowhere near as simple as that, in general, this is an
unsolveable problem. See:
https://tools.ietf.org/html/rfc6476#section-6
for a discussion.
Maybe the above wording was not clear. The plaintext in question refers
to that of a single chunk. Here is another suggestion for a specific text:
If a chunk can not be authenticated, implementations MUST discard the
plaintext of that chunk without further processing, and stop
processing the message with an error. Unauthenticated
plaintext MUST NOT be output to other applications or the user.
Truncated, authenticated plaintext MAY be output, if the truncation is
reported as an error to the application or the user after the fact.
In case of truncation, it is true that the (authenticated) beginning of
the whole message might have been output to applications or users. That
is strictly (and vastly) better than outputting tampered plaintext for
any particular chunk. Truncated plaintext can still be detected and the
error can be indicated after the fact.
Aborting an ongoing operation is a failure case that application
developers and users are familiar with. It happens all the time, for
many reasons (for example, lack of disk space or out of memory
conditions, or any number of simple bugs when processing the data). It
is unsurprising, and it can be dealt with at the application and user side.
Tampered plaintext can be dangerous in many surprising and compromising
ways, as the EFAIL researchers have shown. It is not a failure case that
users or application developers are familiar with. They should not have
to deal with it.
If an impossible problem is easily separable in a solvable problem that
achieves 99% of the goals, and an impossible problem for the remaining
1%, that's a resounding success.
Thanks,
Marcus
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp