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

Neil Madden <neil.e.madden@gmail.com> Thu, 19 April 2018 22:03 UTC

Return-Path: <neil.e.madden@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996DD12E867; Thu, 19 Apr 2018 15:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R4CNsluM18qH; Thu, 19 Apr 2018 15:03:36 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 CC099126C3D; Thu, 19 Apr 2018 15:03:35 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id f14-v6so17863645wre.4; Thu, 19 Apr 2018 15:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kjIJ1eI5sVEEXkvj49YozBr9lYWoUWW3OhIcXtRUEEs=; b=pW9b/eoI0Yp6HHJvXYF8TOHV/G4JbGjBuQjZD6BWPfqfLqx8FxN15ZGbq4minSsO3P lVywvBRsusNgZousB6ixDajJrOIBSTOHb1TSjVtaM4ZWNsoiTgBGDjSK+IWyB+L/wgJO Pz40YKlLsHw88ofeDFHWo3lqOfjKiqOdAK3YXY6sxpoDBVokIinecEMyo02YLxR3qNp1 7d989GnkhH2VwtrE8wKAzXjh79ZwBvMmRKcSTfjCVWxLdwE12Sbtwakcs40cuKkM/dSm 8LHV1P/NhxHRZGhJ43zx9kg3n4vmsbl6IDuGmmTPnOR1QhR6THMh66JWivBMA1j0ktTm ChcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kjIJ1eI5sVEEXkvj49YozBr9lYWoUWW3OhIcXtRUEEs=; b=mRBszz7BHhatFNvmqT+k7W6f21Ay4EAVYsMM3gf8e3sQzJA69heEu3fpFZItm+7Fxx I8ccS+UqEor/YswQGa+hW1V8sveotIy4LG9lOsdWGd1Vpb7cL3vn0qUmkmjSwz9e+jdI Z+IIKqOX5QwS0yziW+AFxLQ9XK8LCbzrEY7Na/Fpa5AK6ooOBL96dVC2nRRUZo2YqIn2 y0lE6F95WDEApynDwdPZW4MSu6SJ2CZwT21aQVEMR2BXFJ20RjzREVEGa1aSYJNVJiS1 /FvnzR2+o95Zx+neFMeg7tKfs0yMz593NMIaev8HrdojB0L81fpzAO9DeNnEEKGRStDK aPTQ==
X-Gm-Message-State: ALQs6tBK4MAWlvdZ7ICt/ueZyqAbhIKAktubvSLu6pv2UhfiXjz1MoFp hgbLtc2jbj1g+VYpUoXuySs4nksf
X-Google-Smtp-Source: AIpwx48hc2pJ3gfVM70F8LP93xy+oilLCuspCPMUy+SjNpzdCfxPx8QsjrN8+O4hcVkah2L73vJ1ZQ==
X-Received: by 2002:adf:b71a:: with SMTP id l26-v6mr6122504wre.115.1524175414220; Thu, 19 Apr 2018 15:03:34 -0700 (PDT)
Received: from guest2s-mbp.home (198.179.93.209.dyn.plus.net. [209.93.179.198]) by smtp.gmail.com with ESMTPSA id l73sm222127wma.10.2018.04.19.15.03.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 15:03:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Neil Madden <neil.e.madden@gmail.com>
In-Reply-To: <CAKws9z15m6WY+-mz5D01vxB4s-TE7nQN56=ssYt=vz3z4gAj6A@mail.gmail.com>
Date: Thu, 19 Apr 2018 23:03:31 +0100
Cc: jose@ietf.org, cfrg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBC2F048-C949-4362-8FD0-A43A54767B03@gmail.com>
References: <CAKws9z15m6WY+-mz5D01vxB4s-TE7nQN56=ssYt=vz3z4gAj6A@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/4yFy5imO0dfPc76WZy4R3tjvl8A>
Subject: Re: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2018 22:03:39 -0000

I agree with some of the criticisms of JOSE here, but I have some concerns about the proposed replacement.

Firstly, your blog post states that ECDH in JOSE is only defined for NIST curves. Actually, RFC 8037 [1] defined X25519/X448 for ECDH in JWE and EdDSA for JWS.

Thomas Ptacek also had some good observations about weaknesses of the JOSE standards [2]. 

Two questions then occur to me:
1. Is JOSE fixable or does it need to be replaced entirely?
2. If it needs to be replaced, is PASETO a suitable replacement?

I’ll tackle these in reverse order. I find PASETO interesting, but also find aspects of the design somewhat confusing:

- The basic encryption construction [3] appears (to me at least) to be a novel design based on three passes over the message: once to generate a pseudorandom nonce in an SIV-like construction (but not actually authenticating the message), a second time to encrypt, and then a third time to authenticate the cipher text. Is this a well-studied design? What security goal is it designed to meet? Why not just use SIV mode?

- PASETO still relies on the message to tell it the type of crypto algorithms in use: “v1.local” vs “v1.public” vs “v2.local” etc. Isn’t this “alg” again, but with a more restricted (and higher-level) set of algorithms? I don’t think this is necessary at all - see below for an alternative.

- There are some odd combinations of security levels defined. For instance, v1.local uses untruncated HMAC-SHA384 for authentication (384-bit tag), while v2.local uses Poly1305 (128-bit tag) - so v2 is actually targeting a lower security level for authentication? 

- XChaCha20 has not been formally published before. While it seems an “obvious” translation of XSalsa20 to ChaCha20, I’d prefer that to be independently specified (e.g. by CFRG) before being the recommended choice. XSalsa20 is already published and well known.

- The guidelines in section 3.1 are unclear. For instance, they state that long nonces (> 128 bits) satisfy “some degree of nonce-misuse resistance”, but they do not - at least not in the sense of misuse-resistant authenticated encryption (MRAE). They just make randomly-generated nonces less likely to collide. The security goals should be clearly defined here.

- The guidelines state that public key encryption should be IND-CCA2, but public key encryption is not defined in the spec. It’s not clear that IND-CCA2 is the right security goal here, vs e.g. public key authenticated encryption as in NaCl.

So while I appreciate the streamlined design compared to JOSE, there are enough non-obvious design decisions here that I am reluctant to immediately recommend it as a replacement for JOSE.

But is JOSE fixable instead? I think there is certainly a lot you could do to improve it without completely throwing it away and starting again. The problem is that old standards never really get thrown away, so we end up supporting n+1 standards instead. I think a few basic changes could improve the standards considerably:

1. Deprecating broken/dubious algorithms (like RSA encryption with PKCS#1 v1.5 padding) and proposing modern and robust replacements (like RFC 8037 or my own draft for SIV modes [4]).
2. Moving the “alg” and “enc” headers out of JWE/JWS and instead into JWK so that is the key that determines the algorithm not the message.
3. Deprecating all the ways that you can specify a key in a message, leaving just “kid”.

I think these changes would go quite a long way to making JOSE more robust. It wouldn’t solve everything (and I have more suggestions for another time), but it moves in the right direction. Ultimately I would like JWE to gravitate towards authenticated encryption in both symmetric and public-key settings, and JWS to concentrate on non-repudiation, but that is a larger change.

[1] https://tools.ietf.org/html/rfc8037
[2] https://lobste.rs/s/r4lv76/jwt_is_bad_standard_everyone_should_avoid#c_k91fsa
[3] https://tools.ietf.org/html/draft-paragon-paseto-rfc-00#section-4.3.2
[4] https://tools.ietf.org/html/draft-madden-jose-siv-mode-02

Regards,

Neil Madden

> On 19 Apr 2018, at 15:13, Scott Arciszewski <scott@paragonie.com> wrote:
> 
> 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​​
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg