IETF Logo Mail Archive

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

Jim Manico <jim@manicode.com> Sat, 29 July 2017 18:32 UTC

Return-Path: <jim@manicode.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6F131DA2 for <oauth@ietfa.amsl.com>; Sat, 29 Jul 2017 11:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qto1_xWmGP8k for <oauth@ietfa.amsl.com>; Sat, 29 Jul 2017 11:32:55 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C54D131CFD for <oauth@ietf.org>; Sat, 29 Jul 2017 11:32:55 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id k190so57523952pgk.5 for <oauth@ietf.org>; Sat, 29 Jul 2017 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9A5XMmvzXgFiL6XMdyy0ELoVz1UTBSToMebGNLbhpkk=; b=SVUXeXuabQfDrZ3q7oOSLO7yty+sACggKj+fKK5VbioKJw7hFUso4Vc7J4zumnJUAF yEFH1J7M2NnHRQMzQVVSvC8pQmVTxwuo3d0iL1UeorPFbG/js43gN/lrtDufVJPtJHil m6JO5DXL9FQSTFef1YYcEgFRO8V35G4PPDJgBV2Xto61WiDpWFmpuf4ZS9/AnurRirdM OKxTSblrqchxxLtOulygNV2+FuEJJyF28BYA8IAt1hIcjKwPrSxdD36skOGyMIr86eHZ BUkf05qv2nQNTp/IuYhqi7aEvk3KaUmxiytIprSU8CD6c7TlpMyun7XK7d9vYOx4MVk7 hTOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9A5XMmvzXgFiL6XMdyy0ELoVz1UTBSToMebGNLbhpkk=; b=KzfAPUqOWMFqO+CghxN01QcoASLTL4hNhmTIjaQQQSAJyLu8fTkYv+34WtRJBKaWTz Cf9qTJz0GYIhpxJybQg5WRO9en2BGly0OOw21RxJUbGm9wfQZyb5rtxtEbfNJGBQgBQY QJBHHbjUV89QLZSShVw5d9NOo6PS0gA0tTVCp3OsggUaZKHVrPatXYyGndLeEi+kN0sv zjVZ4suqYF3SrnRVYO7QRybWm4pIuOUGcQlp74xpnD/+2TQPOSxblu1kpozE9fWKHA96 SX8JK++i4HXjNiVNwLM7nPEV+fy1RTOSt69oILfZfB1oyEPdhzXo3oqP7NRsWExrhG4h hyYA==
X-Gm-Message-State: AIVw112JPOdvune4RNOYjeSUOjRt+1bjp/Pe3oFbad+Q8gG1rNcHMO9G xpWLfso4AM3JMh83yh8psQ==
X-Received: by 10.84.229.136 with SMTP id c8mr12047696plk.27.1501353174327; Sat, 29 Jul 2017 11:32:54 -0700 (PDT)
Received: from ?IPv6:2605:e000:112b:c167:5c99:7884:e707:db7c? ([2605:e000:112b:c167:5c99:7884:e707:db7c]) by smtp.gmail.com with ESMTPSA id u67sm1358736pfd.164.2017.07.29.11.32.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 11:32:52 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
Date: Sat, 29 Jul 2017 08:32:51 -1000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A07A5549-3554-42D6-B0ED-3CC62306D1DA@manicode.com>
References: <mailman.4424.1501277231.4234.oauth@ietf.org> <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/at0QvgSBoN7q5GqEgElzpj8dvdo>
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jul 2017 18:32:57 -0000

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.ietf@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

v2.23.0 | Report a Bug | By Email