Re: [openpgp] AEAD Chunk Size

[Bart Butler <[e-mail]>]

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=[e-mail]> wrote:

> 

> 

> > On Mar 29, 2019, at 6:20 AM, Neal H. Walfield [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp