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

Jim Manico <> Sat, 29 July 2017 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32535129ADD for <>; Sat, 29 Jul 2017 13:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 WoXTzHze8WxF for <>; Sat, 29 Jul 2017 13:44:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8420F126CD8 for <>; Sat, 29 Jul 2017 13:44:24 -0700 (PDT)
Received: by with SMTP id u185so17863617pgb.1 for <>; Sat, 29 Jul 2017 13:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=sLB70FbeUTzNVbcR6gyZf20n7AUjG5X86SvGZo69/ds=; b=pI6kCLqRl46XXqTlStha/Af0YlJzNa4oQLxKMmAJ8xJme3mF+/lzQojnyBEd+YvyKN IE7vnJ2oidhRcXBfkSBX1ZdVS1NcrwWvdq5rJt3Vqeku1K8hKLVzGfaxedgMee9rNUhC TYRS4q9FD/7EVZwKC3jK4U+MFsWvYNJDuiNKDwk6Gg81ujWd+tFLawhkNRnGdsfqdPdO DVr2CuJZuE2GOerUIXw/hxG+2HlF23mreFz31IYN5qFIK4ALJbp+Vapm8wdDWJSPRoHk GtZWykv1qkBTe995mOmy3FjZctg7Vn+QyHV/Gwk0jeusHujrmsoP+rANc4S42TJg7bJ4 Xy9g==
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-transfer-encoding :content-language; bh=sLB70FbeUTzNVbcR6gyZf20n7AUjG5X86SvGZo69/ds=; b=ZCr013l6cbTb6mw2BJdegkgk/3ROYkii+7xtkYL3Hent5KOiDNFu2YVm2ESv+3qc+V vZNYlenGjUc+iDMzHeAsRFuRp42GHWZkg+9W5k1EsVogW8m1Qi58GMzNB2+dDdhG7oG/ QvuHKY6QZUD/M+Ky7E61PY+3y42t40ahFuFK6ZpgvE1c/fSkaadK7rfusZ7Aa3cKciln D7giSZcM4k6reCbHSbD6DCvkFACly/fUkm4Q7eG6ik8oOAT+eYtsvZ1DZJ5upG2oyLWJ XJ7rHoseR3MLHvXVi0EPYGsxPaxjz39AfTvJNrT/b2fmlcYrHnzGP5p/gmvBLOxpQqQb pQsg==
X-Gm-Message-State: AIVw110WTJ7zg4/ITdjMaL4r6gfYiICPCGMdMuy+7BoJ/sFGCRSW9U+d sfcg/TLwBqSIBu4prX1T/A==
X-Received: by with SMTP id w3mr11401418pgb.350.1501361063716; Sat, 29 Jul 2017 13:44:23 -0700 (PDT)
Received: from heembo.local ([2605:e000:112b:c167:bc89:293d:29e9:6603]) by with ESMTPSA id f2sm40870231pgc.17.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 13:44:22 -0700 (PDT)
To: Yaron Sheffer <>
References: <> <> <> <>
From: Jim Manico <>
Message-ID: <>
Date: Sat, 29 Jul 2017 10:44:19 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
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:44:26 -0000

This looks like a very reasonable and fairly achievable security defense

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

Jim Manico
Manicode Security