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

From: "jose issue tracker" <[email-masked]>
Date: Wed, 03 Apr 2013 19:52:13 -0000

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

Comment (by [email-masked]):

 This write-up is missing the fact that even if the wrapped keys were
 removed from the integrity calculation, there's still per-recipient
 content in the headers, such as information about the key used for that
 recipient.  So I believe what you're really asking for, Richard, is to
 remove both the wrapped key and the header from the integrity calculation,
 so there is no per-recipient information protected.  (Please correct me if
 I'm wrong.)

 For starters, not protecting the headers could open us up to algorithm
 substitution attacks, because the "alg" and/or "enc" values could be
 modified by the attacker.

 Furthermore, protecting the headers cryptographically binds the
 information in them to the Ciphertext, which is a very good thing.
 Especially given that we've now allowed additional information to be
 passed in the headers (by saying that header parameter values that are not
 understood must be ignored), I fully expect that some of that information
 will only be of any value when cryptographically bound to the Ciphertext,
 so attackers cannot modify it.

 Protecting the headers values is a "secure by default" architecture.  It
 removes the need to ask questions about what attacks are enabled if header
 parameter A or header parameter B can be modified by the attacker, because
 we've taken that possibility away from the attacker.  Especially given
 that we know that we don't know what all the header parameters will be,
 from a security viewpoint, continuing to protect them seems like the only
 sensible choice.

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

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:3>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Thu, 04 Apr 2013 03:52:09 -0000

Comment (by [email-masked]):

 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.
 <http://www.ietf.org/mail-archive/web/cfrg/current/msg03376.html>

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

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:4>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Thu, 04 Apr 2013 16:08:53 -0000

Comment (by [email-masked]):

 This issue has been refered to the CFRG mailing list in order to get a
 clearer idea of what the technical requirements are from the cryptographic
 perspective.  After we get the feedback we can make the decision based on
 both the cryptographic and non-cryptographic criteria we have.

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:5>
jose <http://tools.ietf.org/jose/>