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

["jose issue tracker" <[e-mail]>]

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


Comment (by [e-mail]):

 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.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [e-mail]        |  [e-mail]
     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:4>
jose <http://tools.ietf.org/jose/>