Hi Jon,
As others have noted, there is a lot of confusion on this thread, some of which
you touched in your AEAD Conundrum message, like when we say AEAD should not
release unauthenticated plaintext, do we mean the entire message or the chunk?
Another piece of confusion is that Efail isn't a single vulnerability, it was
several vulnerabilities related (at best) thematically.
So to be very specific, for the purpose of the following discussion, the
advantage of smaller AEAD chunks is specifically to prevent Efail-style
ciphertext malleability/gadget attacks, and the prohibition on releasing
unauthenticated plaintext is applied to individual chunks, which is sufficient
to foil this kind of attack in email.
The kind of attack we are talking about is fundamentally about exfiltration of
plaintext data to an attacker-controlled endpoint. Borrowing from your AEAD
Conundrum message, if the first chunk passes and is released, and the second
chunk fails, that is OK, at least for email, because the part that was modified
(the second chunk) is never released, so you get a truncated message and an
error, but the truncated message without the modifications isn't going to
exfiltrate itself.
Now if releasing ANY authenticated chunk of a message that hasn't been fully
authenticated (in an AEAD sense) is a real problem for your application, I'd
argue that you're trying to make AEAD do something it's not suited for and you
should enforce this in your application if it applies to you, probably by not
streaming.
So to recap, small-chunk AEAD provides specific value in preventing ciphertext
malleability/gadget attacks, particularly in HTML email, which is a common use
case.
What value does large-chunk AEAD actually provide? What I'm getting from the
AEAD Conundrum message is that it's a way for the message encrypter to leverage
the "don't release unauthenticated chunks" prohibition to force the decrypter
to decrypt the whole message before releasing anything. Why do we want to give
the message creator this kind of power? Why should the message creator be given
the choice to force her recipient to either decrypt the entire message before
release or be less safe than she would have been with smaller chunks?
Coming back to Neal's point, it's really hard to see any sort of value in
really large AEAD chunks, because the performance overhead is negligible at
that point and the only security 'benefit' that I can see is the encrypter
trying to use the spec to force the decrypter to not stream, which does not
seem like something at all desirable.
-Bart
P.S. ProtonMail doesn't use V5 keys or the new draft yet, but some users of
OpenPGP.js have started using them with 256kB chunks, so we are not arguing on
behalf of ourselves for the 256kB chunk size. The proposed language seems more
or less OK in this regard, as most implementations will presumably keep 256kB
support so these early adopters will not lose interoperability with their
messages.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 29, 2019 1:42 PM, Jon Callas
<joncallas=40icloud(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:
On Mar 29, 2019, at 6:20 AM, Neal H. Walfield neal(_at_)walfield(_dot_)org
wrote:
As I mentioned earlier, we really need some data on real-world use cases
rather than hypothesising problematic corner cases that will rarely, if
ever,
occur.
Efail occured. Why is that not enough?
Many of us think that Efail is orthogonal to this problem and consequently
while it’s a real issue, as a rationale, it’s lacking.
You might disagree with us, and I respect that. Nonetheless, I find Efail to
be unconvincing. I’d love to debate this further, but do you have another
rationale, or it only Efail?
Jon
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp