#171: Section 4.1.3 "zip" (Compression Algorithm) Header Parameter
Comment (by [email protected]): 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. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- [email protected] | [email protected] 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:2> jose <http://tools.ietf.org/jose/> _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
