On Wed, Mar 29, 2017 at 2:36 PM, Paragon Initiative Enterprises Security Team <[email protected]> wrote: > 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 >> >> Deletions >> >> JWS and JWE >> >> 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. On a higher level, this can lead to reasoning by >> lego. >> >> For all the reasons outlined here and here, the alg header (and algorithm >> agility in its entirety) should be considered harmful. >> >> JWE >> >> Drop the enc header >> >> For the same reason we're dropping the alg header, we should drop the enc >> header. >> >> Consider dropping the zip header >> >> As we've seen with CRIME and BREACH, as well as this error oracle attack >> against 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. >> >> Additions >> >> JWS and JWE >> >> 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. >> >> 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 >> _______________________________________________ >> 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.
But the attacker still gets to choose what version to lie about. Implementers will still have to verify that the expected algorithm (as defined implicitly by the version) matches the inputs. Failure to check inputs has been the cause of all the major vulnerabilities. This plan adds precisely no additional security but comes with great cost for implementers. The bottom line is that implementers of JOSE need to know what they're doing. The expectation that someone can write a JOSE library without understanding cryptographic primitives is unrealistic. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
