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

[John Bradley <[e-mail]>]

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:

> 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
> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose