Subject: [jose] Towards a More Secure JOSE Standard

From: Paragon Initiative Enterprises Security Team <[email-masked]>
Date: Wed, 29 Mar 2017 12:19:52 -0400

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>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Mar 2017 13:22:46 -0500

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-masked]> 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 <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03>, but I have mirrored them below.
> 
>  <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
>  <https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03#new-header-mode>New header: mode
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Paragon Initiative Enterprises Security Team <[email-masked]>
Date: Wed, 29 Mar 2017 14:36:11 -0400

On Wed, Mar 29, 2017 at 2:22 PM, Justin Richer <[email-masked]> 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
>
> secure. Our suggestions are outlined at https://gist.github.com/
> paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03, but I have mirrored
> them below.
>
> <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.
>
>       - RSA-OAEP with MGF1-SHA256 and e=65537 + AES-128-CBC in KEM+DEM
>       for public-key encryption, min. key size: 2048-bit
> _______________________________________________
> jose mailing list
> [email-masked]
​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
​

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 29 Mar 2017 15:29:08 -0400

On Wed, Mar 29, 2017 at 2:36 PM, Paragon Initiative Enterprises
Security Team <[email-masked]> wrote:
>> 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
>>
>> JWS and JWE
>> Drop the alg header
>> 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
>>
>> 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.
>>
>> JWS and JWE
>> New header: ver (version)
>>
>> RSA-OAEP with MGF1-SHA256 and e=65537 + AES-128-CBC in KEM+DEM for
>> ECDSA over secp256r1 (NIST P-256), adhering to RFC 6979 (deterministic
>> ECDSA), for public-key digital signatures
>>
>> Version 3:
>>
>> New header: mode
>> Kind regards,
>> Paragon Initiative Enterprises
> Hi,
> There are more problems than the RS256/HS256 critical vulnerability from
>> 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
> 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.

---

From: Paragon Initiative Enterprises Security Team <[email-masked]>
Date: Thu, 30 Mar 2017 13:52:46 -0400

On Wed, Mar 29, 2017 at 3:29 PM, Nathaniel McCallum <[email-masked]>
wrote:

> Instead,
> >> On Mar 29, 2017, at 11:19 AM, Paragon Initiative Enterprises Security
> Team
> >> <[email-masked]> wrote:
> >>
> >> Hello,
> >>
> >> RSASSA-PSS with MGF1-SHA256 and e=65537 for public-key digital
> signatures,
> >> min. key size: 2048-bit
> >>
> >> Version 2:
> >>
> Instead,

​Nathaniel,

​
> ​But the attacker still gets to choose what version to lie about.

defined implicitly by the version) matches the inputs.
> ​​
> ​​
> Failure to
> check inputs has been the cause of all the major vulnerabilities.
> ​​
> This

for implementers.​

​I'd like to unpack your claims here.

​
> ​
> ​
> ​But the attacker still gets to choose what version to lie about.

defined implicitly by the version) matches the inputs.

​Let's look at version 3 of the original email:

   - HMAC-SHA-512-256: 32 byte signature
   - Ed25519: 64 byte signature (RFC 8032 for reference)​
   - XSalsa20Poly1305: [ciphertext] + [16 byte authentication tag]
   - X25519 + XSalsa20Poly1305: [32 byte ephemeral X25519 public key] +
   [Ciphertext] + [16 byte authentication tag]

The respective libsodium functions here would be: crypto_auth(),
crypto_sign(), crypto_secretbox(), and crypto_box_seal() if you'd like a
reference implementation.

The analogous ​attacks on RS256/HS256 confusion do not apply: If you
attempt to crypto_auth_verify(signature, message, pk) instead of
crypto_sign_verify_detached(signature, message, pk), it will fail in
constant time (i.e. the signature is not long enough).

In fact, in *all* cases the preferred underlying library will fail closed
without leaking useful timing information. Can the same be said of the JOSE
standards?

​
> Failure to check inputs has been the cause of all the major
> vulnerabilities.
>

​No, a badly-written standard that maximizes the joinery between different
cryptography protocols, encourages users to mix-and-match primitives, and
has weird key encapsulation schemes (n.b. AES-GCM does not belong in the
same category as public-key cryptography), while placing all the blame on
libraries and users, and furthermore has not been designed with the
assistance of a professional cryptographer, has been the root cause of all
the major vulnerabilities.

As an industry, we've grown past the point to where we can just blame users
for mistakes enabled by our error-prone cryptographic designs. Has the IETF
lagged behind here?

​
> ​
> This
> ​
> plan adds precisely no additional security ​

​That's an interesting claim, and easily debunked:

By getting rid of RSA PKCS1v1.5 encryption and signing, we eliminate any
chance of Daniel Bleichenbacher's 1998 or 2006 attacks against RSA +
PKCS1v1.5 padding, which increases the security of implementations by a
nonzero amount.

If anyoune would like to argue that PKCS1v1.5 is just fine (insert dog
drinking coffee in a house fire here), be sure to CC some of the TLSWG and
CFRG members; they could use a laugh.

Security Team
Paragon Initiative Enterprises <https://paragonie.com/security>​

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 31 Mar 2017 11:46:07 -0400

On Thu, Mar 30, 2017 at 1:52 PM, Paragon Initiative Enterprises
Security Team <[email-masked]> wrote:
> Nathaniel,
> I'd like to unpack your claims here.
>
> Let's look at version 3 of the original email:
>
> HMAC-SHA-512-256: 32 byte signature
> Ed25519: 64 byte signature (RFC 8032 for reference)
> XSalsa20Poly1305: [ciphertext] + [16 byte authentication tag]
> X25519 + XSalsa20Poly1305: [32 byte ephemeral X25519 public key] +
> The analogous attacks on RS256/HS256 confusion do not apply: If you attempt
> to crypto_auth_verify(signature, message, pk) instead of
> In fact, in all cases the preferred underlying library will fail closed

It can, yes, be said of the many implementations of the JOSE standards
that were not affected by RS256/HS256 confusion.

> No, a badly-written standard that maximizes the joinery between different

Implementations that check the requested algorithm against the key
type and allowed key algorithms are not vulnerable. Hence, the root
cause is a failure to verify inputs.

Yes, it would be nice if the standard was less fragile in this area.
But you're asking for a major change to an existing standard after it
is published and many interoperable implementations exist. You have to
realize this is a (very) hard sell.

>> This
>>
>> plan adds precisely no additional security

(versus other plans with lower costs)

> That's an interesting claim, and easily debunked:
>

Make a proposal to retire or downgrade RSA PKCS1v1.5 encryption and
signing. I'll support it.

Make the same proposal to retire zip. I'll support it.

These are both very achievable proposals that will significantly
reduce our attack surface.

---

From: Paragon Initiative Enterprises Security Team <[email-masked]>
Date: Fri, 31 Mar 2017 11:49:11 -0400

> Security Team <[email-masked]> wrote:

​(SNIP)
​

> realize this is a (very) hard sell.

​The alternative is to tell people don't use JOSE, it's a bad standard
<https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid>
and design a superior alternative to recommend instead. One that has
actually been vetted by cryptography experts.​

​Given only those two options, which would you rather see?

Security Team

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 31 Mar 2017 12:03:39 -0400

These are both applicable here:
    http://rationalwiki.org/wiki/False_dilemma
    https://xkcd.com/927/

It is very reasonable to tell people to ensure that their crypto
library is written by a security professional who understands
cryptography and ensures that inputs are validated.

Is is also sensible to write a follow-up RFC detailing security
considerations for implementers. Once done, you can tell people to
only use JOSE implementations that have performed conformity audits
against the new RFC.

Further, you can make sensible proposals to downgrade the IANA
recommendation level of algorithms subject to various attacks. This
can be done without a new RFC.

These approaches will have a far broader impact on the cryptography
ecosystem than proposing a new standard.

On Fri, Mar 31, 2017 at 11:49 AM, Paragon Initiative Enterprises
Security Team <[email-masked]> wrote:
> (SNIP)
> The alternative is to tell people don't use JOSE, it's a bad standard and
> design a superior alternative to recommend instead. One that has actually
> been vetted by cryptography experts.
>
> Given only those two options, which would you rather see?
>
> Security Team