[jose] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens

[Scott Arciszewski <[e-mail]>]

Dear IETF mailing list members,

There have been many real-world failures of the JOSE family of Internet
Standards since they were published in RFCs 7515-7520.

- Accepting {"alg":"none"} in many implementations allowed attackers to
bypass the protections that JWS were supposed to provide.
- Substituting RS256 with HS256 and using the RSA public key as an HMAC
secret key allowed trivial token forgery.
- JWE with ECIES fell to invalid curve attacks.

I've outlined these criticisms and more in a post titled "No way JOSE!
Javascript Object Signing and Encryption is a Bad Standard That Everyone
Should Avoid" [1] last year.

In addition to the critical vulnerabilities in the JOSE standards, there
are a lot of cryptographic smells to be found, especially in related
standards. Let me give you a brief, concrete example.

Recently, the W3C specification for WebAuthn was circulated on social
media. Upon closer review, it uses COSE (CBOR Object Signing and
Encryption-- a JOSE derivative), which requests the registration of two
classes of public-key signature algorithms [2]:

1. RSA with PCKS1v1.5
2. ECDAA, whose formal definition eschews the use of deterministic nonces [3]
and thereby fails to provide the protection of e.g. RFC 6979

There are a few lessons that I believe we can take away from these facts:

1. User-friendly standards like JOSE are incredibly influential in future
protocol designs.
2. If the decision to design cryptography protocols and/or decide the
primitives used is left to library designers and/or users, rather than
cryptography engineers, they will inevitably choose something dangerous or
terrifying.

There is an elegant solution to this trap we've found ourselves in: Design
an alternative token standard that avoids all of the design deficits that
plague the incumbent standard, but is still easy to use for at least 90% of
the JOSE/COSE use-cases. With that in mind, I'd like to present PASETO.

The first RFC draft is online [4]. As of this writing, we have 11
implementations in 10 different programming languages. [5]

The biggest change from JWT to PASETO is that, instead of an alg header
that MUST be understood and processed by implementations in JWT (which
allows different algorithms to be specified in the attacker-provided token)
in PASETO we use versioned protocols.

* If you're using v1, you're using AES-CTR+HMAC-SHA384 or RSASSA-PSS with
MGF1+SHA384, SHA384, and e=65537.
* If you're using v2, you're using XChaCha20-Poly1305 or Ed25519.

Future versions should be defined by cryptography experts.

Thank you for your time and please let me know if you have any immediate
feedback. If you would like to contribute to the next iteration of the RFC
draft, we're handling this on Github [6].

Note: I'm sending this to the JOSE and CFRG mailing lists. We don't yet
have a Working Group for this project. I'm unsure if a separate one should
be formed or if an existing one would like to contribute to the review and
refinement of this proposed Internet Standard.

[1]: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-
is-bad-standard-that-everyone-should-avoid
[2]: https://www.w3.org/TR/2018/CR-webauthn-20180320/#sctn-cose-alg-reg
[3]: https://fidoalliance.org/specs/fido-uaf-v1.1-id-
20170202/fido-ecdaa-algorithm-v1.1-id-20170202.html#ecdaa-sign
[4]: https://datatracker.ietf.org/doc/draft-paragon-paseto-rfc
[5]: https://paseto.io
[6]: https://github.com/paragonie/paseto/blob/master/docs/RFC/paseto.md

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
​​
<https://paragonie.com/>