Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

From: Matthew Green <[email-masked]>
Date: Sun, 12 Feb 2012 14:23:29 -0500

I'm apologize for stepping into this conversation so late. I recently came across the draft-jones-json-web-encryption spec, and I was surprised to see that it doesn't explicitly mandate the use of authenticated encryption. This seems extremely dangerous to me, and I was hoping I could convince this group to reconsider.

Many of my concerns were already raised by David McGrew in a post he wrote back in November.* David cites most of the academic literature on padding oracle attacks, which are an efficient class of attacks that can be leveraged against unauthenticated encryption modes used in online systems. I wanted to add that this problem is hardly academic. Padding oracle attacks are easy to implement (I've had undergrads code them as an assignment), and there are toolkits available to help people run them on most systems. Moreover, they're almost impossible to defend on without some sort of authentication. This authentication would be provided via an AEAD mode like GCM, or through use of a MAC.

Probably the most relevant example is Jager and Somorovsky's recent attack against the 2002 W3C XML Encryption standard (as implemented in JBoss and Axis2), which serves almost the same purpose as json-web-encryption. Given all the press that attack received, I think would be particularly unfortunate to have this brand new standard fall to same sort of attack.

I understand that the standard gives the /option/ to use authenticated encryption (GCM mode) or unauthenticated CBC-mode. What's missing, I think is the appropriate warning to non-expert implementers. I would phrase it along these lines:

* If you choose to implement this specification using unauthenticated encryption (CBC mode), your ciphertexts will be vulnerable to simple attacks that lead to complete plaintext recovery. Therefore, we do not recommend the use of CBC mode in any application where message confidentiality is critical to system security.

On the other hand, why should you ever have to write something like that into an encryption standard? It seems like the proper solution would be to simply remove the CBC option altogether.

Regards,

Matt Green

* http://www.ietf.org/mail-archive/web/jose/current/msg00304.html

---

From: John Bradley <[email-masked]>
Date: Sun, 12 Feb 2012 16:58:28 -0300

While it would be nice to have GWC on all platforms it is not currently.   openssl is a prime culprit at the moment.  

So totally removing AES-CBC is not practical.  

We have discussed adding MAC integrity to CBC in the next draft.   

The question is should CBC be allowed without integrity.   Personally I would be on the no side of that question.

I don't yet have a sense of the WG on that question.  I do think there is consensus on adding a integrity check to CBC as a preferred option.

John B.

On 2012-02-12, at 4:23 PM, Matthew Green wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Matthew Green <[email-masked]>
Date: Mon, 13 Feb 2012 08:46:13 -0500

Thanks John and Nat, I'm glad to see that the WG is considering the issue. Please count me as strongly in favor of this protection.

John, I agree with your concerns re: GCM and platform dependence. CBC with a MAC on the ciphertext would be a perfectly good alternative. I understand that this requires key derivation for the MAC key, but this shouldn't be too bad.

Finally -- if a first version of the spec does ship without authentication I would advocate putting a strongly-worded warning in the "Security Considerations" section and elsewhere throughout the document!

Regards,

Matt