Hi Derek,
Thanks for your comments.
On Thu, 14 Mar 2019 15:17:41 +0100,
Derek Atkins wrote:
On Thu, March 14, 2019 9:47 am, Neal H. Walfield wrote:
AEAD catches not only these errors, but also providers ciphertext
integrity.
Are you arguing like Werner that catching transmission errors is
enough and that we shouldn't bother with ciphertext integrity?
I don't see how these two are mutually exclusive.
These issues aren't mutually exclusive, and I apologize if I gave you
the impression that I thought they were. I think everyone agrees that
catching transmission errors is desirable. At least, I do :). The
sticking point, AFAICT, is that Werner disagrees that the
specification should guarantee cipher text integrity when streaming.
I'm currently convinced that streaming authenticated plaintext is only
possible if we use small chunk sizes. If we allow large chunk sizes
(e.g., 4 exabytes, which is what the current draft allows), then there
will be cases where an implementation can stream unauthenticated
plaintext, but not authenticated data, and, because it can, it will.
And this is even though pretty much everyone including the IETF (see
RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext.
[1] https://tools.ietf.org/html/rfc5116#section-2.2
Implementations will stream unauthenticated plaintext for
interoperability purposes. Failing to decrypt, because the device
doesn't have enough resources, will prevent users from getting their
work done. And, if security prevents users from getting their work
done, then the security mechanism will be worked around.
Implementations will stream unauthenticated plaintext to keep their
code simple. If we allow implementations to stream unauthenticated
plaintext, then streaming authenticated data becomes a special case.
And, no one likes to maintain two code paths.
Will this happen in practice? IT'S ALREADY HAPPENED. There is
already an OpenPGP implementation written by one of 4880bis's editors
that emits unauthenticated plaintext. Now, this puts pressure on
other implementations to follow suit, because users will inevitably
ask why FooGP can decrypt some messages that BarGP can't.
I think the only way to prevent this is to ensure that unauthenticated
streaming provides as few advantages over authenticated streaming as
possible. This means ensuring that the amount of data to be buffered
is small, and making the implementation work as simple as possible by
using a fixed chunk size.
When I originally thought about this problem, I thought that
introducing a soft threshold could be an option. But, I've since
concluded that this doesn't help. Although a sender could use a small
chunk size to ensure that a compliant receiver doesn't emit
unauthenticated data, an attacker can change the chunk size in the
intercepted message, and successfully conduct an EFAIL-style attack.
(See [2].)
[2] https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U
Derek, I hope this clarifies my position. Do you now also agree that
ensuring cipther text integrity when streaming is desirable? If not,
what concerns do you have?
Thanks!
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp