Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A2124D68 for ; Thu, 19 Apr 2018 07:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paragonie-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnO9DOYPjLns for ; Thu, 19 Apr 2018 07:13:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7441241FC for ; Thu, 19 Apr 2018 07:13:33 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id t27-v6so4945067oij.9 for ; Thu, 19 Apr 2018 07:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragonie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=aMURLuhjMUgS2d5GcH7gudocW2fqckQEqTaF6OpV2rw=; b=mMJ9yEP2NHM+enqd4ecwRBiRB8feCCh9ucAqfzu4N0aJNHdHbqQNN8gf5YRl2W1FaT 2azJ+kpkJil5DmnxgWUccbiFOKofk5uz5unLUCrCLmonLwvdS7KOXI0RUmh7TX706isv nO0n0N+iFc7Ps3YdRxG6fUfAqFxSSpArKRDHI56rIZyBn04Oqg4wirHDxm1RL7WfoYXa +oef6l/ZLa8uRbF9YX3WGVxhLlfNZy/yBw1gRqsfHnyqXgM7MlzAuAF1yuxlkeemRyOg H9/UumtTAUPc7dFhgrVuSfmHtyCFjNNAGy5fl6w/jMd9YSOZNk2kbPSfT0GpwIOU88kC Kp3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aMURLuhjMUgS2d5GcH7gudocW2fqckQEqTaF6OpV2rw=; b=Bboa9OdGNjNVUVbDnoLeRSEJYeMJK10xxAkVjXzaIWmSIQ2F2EphtPXrSpaahiRoYL 4SspYyhoyy7leUr+6f9ARKuiDbjkhFfn3RAkVDCrShMX3gxk7p+HaTy9vP/zFv0S5rMS b2eM2jYk2A4mQC8nEGboZPVg+fPEw6qRg7HcQl57XeKD9poFhEpa9oCPKVoWgpKP0P6F QsJzu5bTvz+O3KVjTs9iysvNiwT+j+xrHKqEr6SzR5OGBj/SFpQKcL/YrQdB1sFpyO/k TieN5HJPK8lZYDuJi132ozoESSmYEjbEHMvyoFpNgKza/HkmozsiqDLxL+yRQ+b17gC9 LtGQ== X-Gm-Message-State: ALQs6tBOgDrzGyjXVUURDxGIWL4+3X16OmZklcagO3AGaGg6MWNr1LXW V1pLt0P5eIKcSgUp80T4grnOLkEn503fwXz9FYabeFiim88= X-Google-Smtp-Source: AIpwx49xr/7TFQKF8sMzMu+9WE2wFfVC7j0b8ROCFkovbOjc5Fm3xg5vFRR3uBWadPRC08jlMjhfnn5O9nCS+UhtqTM= X-Received: by 2002:aca:b80a:: with SMTP id i10-v6mr3903280oif.72.1524147212663; Thu, 19 Apr 2018 07:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:55e9:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 07:13:31 -0700 (PDT) From: Scott Arciszewski Date: Thu, 19 Apr 2018 10:13:31 -0400 Message-ID: To: jose@ietf.org, cfrg@ietf.org Content-Type: multipart/alternative; boundary="000000000000324da0056a342dc9" Archived-At: Subject: [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 14:13:40 -0000 --000000000000324da0056a342dc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D65537. * 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 =E2=80=8B=E2=80=8B --000000000000324da0056a342dc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IETF mailing list members,

There have been many r= eal-world failures of the JOSE family of Internet Standards since they were= published in RFCs 7515-7520.
- Accepting {"alg":&q= uot;none"} in many implementations allowed attackers to bypass the pro= tections that JWS were supposed to provide.
- Substituting RS= 256 with HS256 and using the RSA public key as an HMAC secret key allowed t= rivial token forgery.
- JWE with ECIES fell to invalid cu= rve attacks.=C2=A0

I've outlined these criticisms and more in a po= st 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 standard= s, there are a lot of cryptographic smells to be found, especially in relat= ed standards. Let me give you a brief, concrete example.

Recently, th= e W3C specification for WebAuthn was circulated on social media. Upon close= r review, it uses COSE (CBOR Object Signing and Encryption-- a JOSE derivat= ive), which requests the registration of two classes of public-key signatur= e algorithms [2]:

1. RSA with PCKS1v1.5
2. ECDAA, whose formal definition eschews the use of d= eterministic nonces=C2=A0<= span style=3D"color:rgb(34,34,34);font-family:monospace,monospace;font-size= :small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:no= rmal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px= ;text-transform:none;white-space:normal;word-spacing:0px;background-color:r= gb(255,255,255);text-decoration-style:initial;text-decoration-color:initial= ;float:none;display:inline">[3] and thereby fails to provide the protection= of e.g. RFC 6979

There are a few lessons that I belie= ve we can take away from these facts:

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

There is an elegant so= lution to this trap we've found ourselves in: Design an alternative tok= en standard that avoids all of the design deficits that plague the incumben= t 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, w= e 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 an= d processed by implementations in JWT (which allows different algorithms to= be specified in the attacker-provided token) in PASETO we use versioned pr= otocols.
* If you= 're using v1, you're using AES-CTR+HMAC-SHA384 or RSASSA-PSS with M= GF1+SHA384, SHA384, and e=3D65537.
* 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 yo= u 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].

<= div class=3D"gmail_default">Note: I'm sending th= is to the JOSE and CFRG mailing lists. We don't yet have a Working Grou= p 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 t= his proposed Internet Standard.
<= br>
[1]: https://paragonie.com/bl= og/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
[2]: https://www.w3.org/TR/2018/CR-webaut= hn-20180320/#sctn-cose-alg-reg
[3]:=C2=A0https://fidoalliance.org/specs/fido-uaf-= v1.1-id-20170202/fido-ecdaa-algorithm-v1.1-id-20170202.html#ecdaa= -sign
[4]:=C2=A0https://datatracker= .ietf.org/doc/draft-paragon-paseto-rfc
[5]: https://paseto.io
[6]:=C2=A0= https://github.com/paragonie/paseto/blob/master/docs/RFC/paseto.md<= /font>

=
Scott Arciszewski
Chief Development Officer

<= div dir=3D"ltr">
--000000000000324da0056a342dc9--