#4: Remove wrapped keys from integrity check (allow separation of keys from data)
Comment (by [email protected]): 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- [email protected] | [email protected] 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/> _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
