Hello, We've outlined some suggestions to make a JOSE replacement/upgrade more secure. Our suggestions are outlined at https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03, but I have mirrored them below.
Changes to JOSE that will prevent insecurity <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#deletions> Deletions <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#jws-and-jwe>JWS and JWE <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#drop-the-alg-header>Drop the alg header Neither JOSE users nor JOSE library designers should be required to understand cryptography primitives. At a lower level, this can lead to badly implemented primitives <http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1>. On a higher level, this can lead to reasoning by lego <http://www.cryptofails.com/post/121201011592/reasoning-by-lego-the-wrong-way-to-think-about> . For all the reasons outlined here <https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid> and here <https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web-tokens>, the alg header (and algorithm agility in its entirety) should be considered harmful. <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#jwe> JWE <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#drop-the-enc-header>Drop the enc header For the same reason we're dropping the alg header, we should drop the enc header. <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#consider-dropping-the-zip-header>Consider dropping the zip header As we've seen with CRIME <https://en.wikipedia.org/wiki/CRIME> and BREACH <http://breachattack.com/>, as well as this error oracle attack against iMessage <https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-imessage/>, compression can introduce side-channels that totally undermine confidentiality. This one is less of a hard-and-fast requirement to make JOSE secure, but I still strongly recommend it. <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#additions> Additions <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#jws-and-jwe-1>JWS and JWE <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#new-header-ver-version>New header: ver (version) Instead of letting library developers and users mix-and-match cryptography algorithms, the only choice they should be given is, "Which version are we using?" Versions can look like this: - Version 1: - HMAC-SHA256 for shared-key authentication - AES-128-CBC + HMAC-SHA256 in Encrypt-then-MAC mode for shared-key encryption - RSA-OAEP with MGF1-SHA256 and e=65537 + AES-128-CBC in KEM+DEM for public-key encryption, min. key size: 2048-bit - RSASSA-PSS with MGF1-SHA256 and e=65537 for public-key digital signatures, min. key size: 2048-bit - Version 2: - HMAC-SHA256 for shared-key authentication - AES-256-GCM for shared-key encryption - ECDH over secp256r1 (NIST P-256) + AES-256-GCM for public-key encryption - Libraries must verify that the point is on the curve - ECDSA over secp256r1 (NIST P-256), adhering to RFC 6979 (deterministic ECDSA), for public-key digital signatures - Version 3: - HMAC-SHA512-256 for shared-key authentication - As per NaCl, this is HMAC-SHA-512 truncated to 256 bits, not HMAC-SHA-512/256. - Xsalsa20poly1305 for shared-key encryption - X25519 + Xsalsa20poly1305 for public-key encryption - Ed25519 for public-key digital signatures Libraries that support version 3 SHOULD NOT support version 1. <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#new-header-mode>New header: mode Only four options (case-insensitive): - se = Shared-key Encryption - sa = Shared-key Authentication - pe = Public-key Encryption - ps = Public-key digital Signatures Kind regards, Security Team Paragon Initiative Enterprises <https://paragonie.com/security>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
