Subject: Re: [jose] #171: Section 4.1.3 "zip" (Compression Algorithm) Header Parameter

From: "jose issue tracker" <[email-masked]>
Date: Tue, 10 Sep 2013 23:33:19 -0000

#171: Section 4.1.3 "zip" (Compression Algorithm) Header Parameter

Description changed by [email-masked]:

Old description:

> A.  Should compression be allowed for JWS?
>
> B.  Redundant statement "If no 'zip' parameter..." and should be removed.
> This is implicit.
>
> C.  Raise the head of the argument from Richard about does this need to
> be integrity protected.

New description:

 A.  Should compression be allowed for JWS?

 * WON'T FIX - Mike says this was discussed and resolved - I don't remember
 doing so and it seems dumb that we don't support this.

 B.  Redundant statement "If no 'zip' parameter..." and should be removed.
 This is implicit.

 C.  Raise the head of the argument from Richard about does this need to be
 integrity protected.

 * WON'T FIX - Mike claims that EKR said it needed to be protected.  I
 can't see any reason why it would make any difference as the content will
 either be understandable or not when decrypted.  If I remember I might ask
 EKR directly at the next meeting.

--

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

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

---

From: "jose issue tracker" <[email-masked]>
Date: Thu, 12 Sep 2013 13:52:26 -0000

Comment (by [email-masked]):

 It seems like poor practice to not integrity protect the zip parameter.

 If the content is compressed, and an intermediary removes the zip
 parameter, then the recipient will successfully (authentication will
 succeed) decrypt the message to Compress(Plaintext) rather than the
 intended Plaintext.

 Similarly imagine if the plaintext happens to be compressed content.  If
 an intermediary adds a zip parameter, now the recipient's view of the
 successfully authenticated and decrypted content will instead be
 Decompress(Plaintext) rather than the intended Plaintext.

 I can't think of any specific examples of how these two issues could be
 exploited, and I suppose it would be dependent on the implementing
 application.  But it seems like poor practice for an authenticated
 encryption scheme to provide any ambiguity of what the authenticated
 plaintext is.

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