Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data)

"jose issue tracker" <> Thu, 04 April 2013 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A860111E80A5 for <>; Wed, 3 Apr 2013 20:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DLt7fqTFDPog for <>; Wed, 3 Apr 2013 20:52:15 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 1985611E80A4 for <>; Wed, 3 Apr 2013 20:52:15 -0700 (PDT)
Received: from localhost ([]:34503 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1UNbDd-0003Av-Pm; Thu, 04 Apr 2013 05:52:09 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "jose issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: jose
Date: Thu, 04 Apr 2013 03:52:09 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 4
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Resent-Message-Id: <>
Resent-Date: Wed, 3 Apr 2013 20:52:15 -0700 (PDT)
Subject: Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data)
X-Mailman-Version: 2.1.12
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Apr 2013 03:52:15 -0000

#4: Remove wrapped keys from integrity check (allow separation of keys from

Comment (by

 Responding to each of your paragraphs in parallel...

 You are correct.  In "wrapped key", I meant to include the parameters
 involved in key wrapping along with the actual octets of the wrapped key.

 Russ Housley nicely summarized on CFRG why these "algorithm substitution
 attacks" are not actually attacks.

 Whether or not cryptographically binding header information to the
 ciphertext is a "very good thing" depends on your application.  Certainly,
 there are applications that do not care at all about this binding -- for
 example, applications that just want to use the header to carry encryption
 parameters, such as the current XMPP e2e proposal.  Applications that do
 care should just wrap the JWE in a JWS to achieve that binding, instead of
 burdening every application in the world with their requirements.

 Header parameters specify inputs to encryption algorithms.  If there is an
 attack that can be accomplished by changing the parameters of an
 algorithm, that is a flaw in the algorithm, and there's nothing this
 format can do to help.  It's also rather naïve to claim that by adding
 integrity protection, you've taken away the attacker's ability to change
 things.  The attacker can still change things and cause the recipient to
 perform unintended cryptographic operations, it's just that this will be
 detected later on.  For example, suppose that an attacker intercepts an
 object encrypted with GCM, and changes it to use CBC+HMAC.  The recipient
 will pull the "enc" parameter out of the header (the bad one, that says
 CBC+HMAC) and process the entire object before realizing that he's done
 the wrong thing.  So all you've really done is shift from one class of
 oracle attacks to another.

 Taking all the above into consideration, we still have yet to hear a
 concrete security benefit to header integrity protection.  On the other
 side, the recent CFRG thread demonstrates that there is real harm in
 header integrity protection, in that it is incompatible with GCM.  GCM is
 not an acceptable cost.  We should kill header integrity protection

 Reporter:               |       Owner:  draft-ietf-jose-json-web-        |
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  encryption             |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |

Ticket URL: <>
jose <>