Re: [OAUTH-WG] JWT BCP on Compression in JWE
Hi Yaron, I don't actually know, which is why I raised the question in hopes that, if possible, the BCP could provide some practical and actionable advice. But I'll try and explain my (maybe naive) thoughts. As I understand it CRIME/BREACH are adaptive-chosen-plaintext attacks that work via malicious scrip in the user's browser that makes requests to the target domain. By observing the size of the compressed data relative to specifically crafted data in requests and adjusting subsequent requests based on the observation, it's possible to deduce the value of the session cookie with a few thousand requests (the few thousand number comes from "How practical is it?" at http://breachattack.com/). Typical JWT usage is an id_token, OAuth access token, or session token where the content of the token is user data and context info. The issuer of the token controls the claims in the token, which are likely user info sourced from a directory or similar. Some of that data might be controllable by the user though the ability to manage pieces of their own profile data (like address, phone, etc.) or maybe particular aspects of the session. But the opportunity for an attacker to control the encrypted data with repeated adaptive values isn't present in the same way that it is in the TLS HTTP case. The two situations seemed distinct enough that it wasn't clear to me that a line should be drawn from CRIME/BREACH to the use of compression in JWE/JWT being automatically bad. On Fri, Jul 28, 2017 at 11:57 PM, Yaron Sheffer 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 > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT BCP on Compression in JWE
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 >>> 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
Re: [OAUTH-WG] JWT BCP on Compression in JWE
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 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT BCP on Compression in JWE
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 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT BCP on Compression in JWE
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
