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

Brian Campbell <> Mon, 31 July 2017 12:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BB861321BB for <>; Mon, 31 Jul 2017 05:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0fEOR32bB_Wq for <>; Mon, 31 Jul 2017 05:24:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CCD81321B4 for <>; Mon, 31 Jul 2017 05:24:39 -0700 (PDT)
Received: by with SMTP id t86so10494185pfe.2 for <>; Mon, 31 Jul 2017 05:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6GJ5NxxVLMJieD5FQgDfsFdDr4hobMRPZVv7sGWHQ6Q=; b=IMkBpG0W9LFSjJ5Rtm2dyKIe26xAmD3Y4jxuNODQb6QSPGX9sGo+qUjVyRgmY+UZ2i qbBUUDf6xxqdncGoVtFwMgUzQFbvo0+rGa2sEQxyOlvvybTODwtQEC9lNsoykWk9NJc/ FhRgLGqWxX+gKb1zZaDd54JwA6UbUlO3FZNvk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6GJ5NxxVLMJieD5FQgDfsFdDr4hobMRPZVv7sGWHQ6Q=; b=tr3pMqS7VnvAYW4iYr9iT3KwMHbA+PHh2NtmaoWqIkEGwYzKZ/3WW08t9mTyaw2CCz g5hTuosBgf1It7KjJ9Lg1a+pycCD7gjRSSCaiU5St/nqFsQvIxLq92+8LU8e9HdBoJiz Id2JIrC3wfECgVTYh8WetsGKep7VLJMkkL1lj6Qtzkn2sAOOf8+iCq1FiTmIEW26axEw ijEA7+2bi9m24mCKkIVf864BERSbF6If4luWElx9xIi6gqP+/vIz5qvUe3+T+W33lDiy WEx3yxSAH1Hl4pk8Y1ueAOdCrF3+gFu9I5LW/ebmJx/BCTdAxqA4RO5Lfo1Is73jQYff QTCA==
X-Gm-Message-State: AIVw113huaZhMK/APltMTZdGMSz5mHlVjcA8zZ02iI2kK2RmhVGKyhRf kd48F6PjVnqoiUWgs2rWd78/ulH8LSkMSqC2TJnKoyeVHjIRhBPYwugIjVKfLqLNKJea2bGZl7Y TFwo3
X-Received: by with SMTP id d1mr17155734pli.17.1501503878655; Mon, 31 Jul 2017 05:24:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 31 Jul 2017 05:24:08 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Mon, 31 Jul 2017 06:24:08 -0600
Message-ID: <>
To: Yaron Sheffer <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="f403045d1f5e512d0505559c1dd6"
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: Mon, 31 Jul 2017 12:24:41 -0000

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

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 <>

> 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

*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.*