Re: [OAUTH-WG] JWT BCP on Compression in JWE

Yaron Sheffer <> Sat, 29 July 2017 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE2DA131E0B for <>; Sat, 29 Jul 2017 13:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K_tcbVITqnCm for <>; Sat, 29 Jul 2017 13:22:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C849A131DFD for <>; Sat, 29 Jul 2017 13:22:23 -0700 (PDT)
Received: by with SMTP id 12so165985394wrb.1 for <>; Sat, 29 Jul 2017 13:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G9hLNLa8lipQTjorwLjl8JN+MWEnt4vku7irGqeCmDI=; b=f807Ny7kpyzE3NaHDHLzV+esle5OEGQNNh/aYttw9MQJo0VVabcYc5f1HHlswXLGo8 9SXtz/iQ9JwPdym1sJEpQXTNY/im2CZe6mHu1m0LgSRokyEbMOuAzP79Zi3NbtUgLgI9 tY48M3O13/KYc2coLcOn0XntFIeppgCxZF9402Oq4E6VzhGCV7mQLDTcLfp4V+VCPNBY nApm0Hr2CWd5W+VK7w9FB5r7W9WSp4iC2cX1RGE1k/lwZlWDO7Ek8b/fy7PeWt9YIJf1 CMIKW9PgWMDRPDKjF45yRZkBEqkBDk4nYBYpX24Z8zHlz0s8tBFLixYg8Tz/RjW7qC8f VOvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G9hLNLa8lipQTjorwLjl8JN+MWEnt4vku7irGqeCmDI=; b=qZMpIx04QDEZ0zYV7WbGaZZzgEiMTjkJhMo8YZMqn93Qnc9wpI9WCBkMAZgNXr0ph9 gMHhouZCLL1uPiiVo1YhVzIdRbW2d5Q9cxjuHUUwDY3aIbY/tt2jH6ehY1Jx3sbo2cje 6QFfXGxn5KZb00t72uuxKPQ2Xe4X3tWjzxR047osEiKOelEKkmd4SHHIhdpFIstxJzli nwECsgFNf6w21rCUFJmY98vzby72OH1pg7OCgS0sMYHTeqg3Si+ZdB1dM1TolWeHkECf WcMSShbXlXHS9dPbbaVU5GPQnDloMnkhSn/ZQUCR/ayUWgQTxzuIrcEKK2Ln3dnVHNE9 9lqQ==
X-Gm-Message-State: AIVw110ThlpkcT6Ny2II2ESNJwMr3Q3LiMaZzEox4yAAOFT2lXnTkfu3 GaR8l9Nwa+UVUK/k5KY=
X-Received: by with SMTP id o3mr8646696wrb.110.1501359742052; Sat, 29 Jul 2017 13:22:22 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v8sm26083019wrd.28.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 13:22:21 -0700 (PDT)
To: Jim Manico <>
References: <> <> <>
From: Yaron Sheffer <>
Message-ID: <>
Date: Sat, 29 Jul 2017 23:22:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Jul 2017 20:22:26 -0000

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.


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