This looks like a very reasonable and fairly achievable security defense feature.
So would you suggest that the core JWE standard provide clear guidance to library authors about when to use compression? Would you also suggest that we need additional flags on JWT elements that do or do not need to be compressed so libraries can selectively compress JWT? We can't fix the past but we can certainly provide more targeted advice as to how to handle this risk. I'd be glad to help. - Jim On 7/29/17 10:22 AM, Yaron Sheffer wrote: > Hi Jim, > > The problem is not the encryption of attacker-controlled data. The > problem is the interaction between this encryption and compression. > > If you don't need compression, you're good. You're mostly OK if you > can compress only the non-attacker controlled data, however this could > potentially leak information about ciphertext. > > This is all very use-case specific and fragile, so I think a > reasonable recommendation is: > > - Avoid transparent compression in generic JWS/JWE libraries. > - Only compress data at the application layer, but bear in mind that > the length of compressed+encrypted data leaks information about > cleartext. > > Thanks, > Yaron > > On 29/07/17 21:32, Jim Manico wrote: >> Yaron, >> >> As a developer, I can think of many scenarios where the attacker >> controls some of the plaintext yet I still need encryption services >> of some kind. What are the proper crypto controls that allow >> developers to do this safely? I think that's the better question >> right now. >> >> Aloha, >> -- >> Jim Manico >> @Manicode >> >>> On Jul 28, 2017, at 7:57 PM, Yaron Sheffer <yaronf.i...@gmail.com> >>> wrote: >>> >>> Hi Brian, >>> >>> These two attacks on TLS are only examples of the breakage that can >>> occur when the adversary can control the plaintext to some degree >>> (even a small piece of the plaintext, e.g. a malleable HTTP cookie >>> can result in decryption of the whole message). Similar attacks were >>> demonstrated in IPsec. Can you please add details on why typical use >>> of JWT would not be susceptible to these attacks? >>> >>> Thanks, >>> Yaron >>> >>>> On critique of JWT I've seen a few times can be paraphrased as "JWT >>>> supports compressed plaintext so, because of CRIME and BREACH, it is >>>> dangerous and stupid." It's very possible that I am stupid (many >>>> on this >>>> list will likely attest to it) but I don't see the applicability of >>>> those >>>> kinds of chosen plaintext attacks aimed at recovering sensitive >>>> data to how >>>> JWT/JWE are typically used. >>>> >>>> I think it would be useful, if during the development of the JWT >>>> BCP, the >>>> authors or chairs or WG could somehow engage some experts (CFRG?) to >>>> understand if there's any real practical advice that can be given >>>> about >>>> using compression with JWE and the risks involved. >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth -- Jim Manico Manicode Security https://www.manicode.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
