IETF Logo Mail Archive

Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

Matthew Green <matthewdgreen@gmail.com> Sun, 12 February 2012 19:23 UTC

Return-Path: <matthewdgreen@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDDC21F853E for <jose@ietfa.amsl.com>; Sun, 12 Feb 2012 11:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIopryKyBiLN for <jose@ietfa.amsl.com>; Sun, 12 Feb 2012 11:23:28 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7168D21F8537 for <jose@ietf.org>; Sun, 12 Feb 2012 11:23:28 -0800 (PST)
Received: by qafi29 with SMTP id i29so1210819qaf.10 for <jose@ietf.org>; Sun, 12 Feb 2012 11:23:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=ihIr3+WjnSw3MpA1tcruIRzyXMScQ1fuvBqlh3AGO8I=; b=yHb8WS4dqke2UZd7P1O+uzElsl59OEgvJ6p+S9sJO+LOykCnyYccXpYV1pxRgoicwt QPxL80Pa5n8pvKPa+GDmmNanK4LLiAi1SitYiwAc6pl1e8a7GssH/wV6EiFkWxmNEf8j mMhMHP8FL8pRvWOS8DIYVNnRvcKOcD8y61XTA=
Received: by 10.229.137.142 with SMTP id w14mr386879qct.84.1329074608001; Sun, 12 Feb 2012 11:23:28 -0800 (PST)
Received: from [192.168.1.11] (c-76-21-153-251.hsd1.md.comcast.net. [76.21.153.251]) by mx.google.com with ESMTPS id r10sm28705189qaz.7.2012.02.12.11.23.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 11:23:27 -0800 (PST)
From: Matthew Green <matthewdgreen@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 12 Feb 2012 14:23:29 -0500
Message-Id: <193BB50D-89DF-43DD-93A1-9483217BC5A1@gmail.com>
To: jose@ietf.org
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Feb 2012 19:23:29 -0000

I'm apologize for stepping into this conversation so late. I recently came across the draft-jones-json-web-encryption spec, and I was surprised to see that it doesn't explicitly mandate the use of authenticated encryption. This seems extremely dangerous to me, and I was hoping I could convince this group to reconsider.

Many of my concerns were already raised by David McGrew in a post he wrote back in November.* David cites most of the academic literature on padding oracle attacks, which are an efficient class of attacks that can be leveraged against unauthenticated encryption modes used in online systems. I wanted to add that this problem is hardly academic. Padding oracle attacks are easy to implement (I've had undergrads code them as an assignment), and there are toolkits available to help people run them on most systems. Moreover, they're almost impossible to defend on without some sort of authentication. This authentication would be provided via an AEAD mode like GCM, or through use of a MAC.

Probably the most relevant example is Jager and Somorovsky's recent attack against the 2002 W3C XML Encryption standard (as implemented in JBoss and Axis2), which serves almost the same purpose as json-web-encryption. Given all the press that attack received, I think would be particularly unfortunate to have this brand new standard fall to same sort of attack.

I understand that the standard gives the /option/ to use authenticated encryption (GCM mode) or unauthenticated CBC-mode. What's missing, I think is the appropriate warning to non-expert implementers. I would phrase it along these lines:

* If you choose to implement this specification using unauthenticated encryption (CBC mode), your ciphertexts will be vulnerable to simple attacks that lead to complete plaintext recovery. Therefore, we do not recommend the use of CBC mode in any application where message confidentiality is critical to system security.

On the other hand, why should you ever have to write something like that into an encryption standard? It seems like the proper solution would be to simply remove the CBC option altogether.

Regards,

Matt Green

* http://www.ietf.org/mail-archive/web/jose/current/msg00304.html

v2.23.0 | Report a Bug | By Email