Re: [jose] Towards a More Secure JOSE Standard

[Paragon Initiative Enterprises Security Team <[e-mail]>]

On Wed, Mar 29, 2017 at 2:22 PM, Justin Richer <[e-mail]> 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
> <[e-mail]> 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
> [e-mail]
> 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>
​