On Wed, Mar 29, 2017 at 2:22 PM, Justin Richer <[email protected]> wrote:
> If the problem is substituting “alg: RS256” with “alg: HS256” or the like, > how is that any different from substituting “mode: ps” with “mode: sa”? > > > There have been some reasonable arguments for removing the algorithm > selection from the JOSE package, but this proposal doesn’t do that. > Instead, it simply defines *new* headers for algorithm selection. Ergo, > unless I’m missing a key point here, this is just kicking things down the > road a little bit. > > — Justin > > On Mar 29, 2017, at 11:19 AM, Paragon Initiative Enterprises Security Team > <[email protected]> wrote: > > 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 > > > Hi, > If the problem is substituting “alg: RS256” with “alg: HS256” or the like, > how is that any different from substituting “mode: ps” with “mode: sa”? > > There are more problems than the RS256/HS256 critical vulnerability from 2015, but nonetheless, you raise a good point: The mode should be decided out-of-band, not supplied by the attacker. Therefore, the mode header must be made optional (i.e. it's purely informational) and implementations should be encouraged to only operate in one mode at a time (i.e. not decided by the message they receive). > > There have been some reasonable arguments for removing the algorithm > selection from the JOSE package, but this proposal doesn’t do that. > Instead, it simply defines *new* headers for algorithm selection. Ergo, > unless I’m missing a key point here, this is just kicking things down the > road a little bit. The previous standard allowed people to choose which hash function, which of the NIST P-curves, etc. to use. The new proposal only allows for one cipher/algorithm per use-case. These algorithm decisions should be made by experts and given as non-tweakable, hard-coded configuration options. There is no "a little of column A, a little of column B", you either use version 2 or version 3. Security Team Paragon Initiative Enterprises <https://paragonie.com/security>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
