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

Neil Madden <> Mon, 23 April 2018 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2477412D86A; Mon, 23 Apr 2018 09:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vEx3WuERg2EJ; Mon, 23 Apr 2018 09:43:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75A0112D86E; Mon, 23 Apr 2018 09:43:29 -0700 (PDT)
Received: by with SMTP id p5-v6so15321225wre.12; Mon, 23 Apr 2018 09:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZcFD5jt65Gx2YcBO/WVu28oyWo6kAOE3UXrPdq7zd0U=; b=pfHUJWzvBmYVtuu/Q5biUjwp2WCqCG/G7j8hs87W/2obG54J5KUMgrsUGotBXKFIuk ocnGKjf9UnCbDqh6m/abKB5HqSUrU1te2re0TnLPiWakYtoYR4yFsHcQ+riNgET2T3+F J31h6plphu4uN4NNNnPmSLFM7ceKlPHSPj4uX6DfJQfTNDSlz/KaZqR5V714fJwdklJq jgVWmLiqx0PL3tFlhywllycANgy+bq5VNRJvk/lKSsCoK/RchLzUoCDYowIFjYysbluK Js4KePXiyDp/fLm4wz8M/+ha+sVX0AdMkDeaqLcxndL+17mqr/5xw/PLAWrNchzljjE2 faZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZcFD5jt65Gx2YcBO/WVu28oyWo6kAOE3UXrPdq7zd0U=; b=Y5rkJCnp/hDOAoALpluNkw52cWMqBiY6XENWlOAeNqKCCV6bTwHbsxJGyI8DGRneuW VItuJsxpI6dxddEutrbHr0acFbNJo5T3pH3a7ypABvvD6AB4wqVSMtB/jR4PbXPIa+7Y 7Bv2Hlloz0+idsH0ksb8NOctknYNok7G7vgiWYR0LARh1wRhTHWixUhB8xmPgDE9B6hU gD7hPGbQxZK5tpRV/GiNjwDC2nMJZ8u3CS8tAWJjQ7JcbKz0+A4B8+//+lCAKQI4fHc5 X2Nb30oLxwe6wCd/Fe+3XT5akTH/CDMdWa4w2InrcBy9lHLxaKsiFxAyaq1Qqrr/2r2Z 5bLQ==
X-Gm-Message-State: ALQs6tCIjaYTWNbT5No7Hm/BC2Acjg/8GhuzfxJzo/ll609gK4+dtDzK N9sWK6irexevFk9MSJJZC/I2wqGsKfU=
X-Google-Smtp-Source: AIpwx48qeEQRueb+Omqc1RAexjzhXaYpGb4pd6w84w0zs0JVUArTPKNo7Ew7N8NKmX9wuOeyLECebw==
X-Received: by with SMTP id 123mr9811810wmm.75.1524501807897; Mon, 23 Apr 2018 09:43:27 -0700 (PDT)
Received: from guest2s-mbp.home ( []) by with ESMTPSA id n14-v6sm15221857wrj.16.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 09:43:26 -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 <>
In-Reply-To: <>
Date: Mon, 23 Apr 2018 17:43:25 +0100
Cc: Mike Jones <>, Carsten Bormann <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: David Adrian <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens
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: Mon, 23 Apr 2018 16:43:34 -0000

> On 23 Apr 2018, at 14:44, David Adrian <> wrote:
> > If we have to invent a new standard each time an existing standard is implemented with a security flaw, we have a lot of work to do.
> You fundamentally cannot fix a standard with unusable to the point of broken negotiation by extending the negotiation. If you don't want PASETO to be a new standard, call it JOSEv3.

I don’t believe that PASETO is actually fundamentally different from JOSE in this respect. Is there a meaningful distinction between v1.local.<token> and {“alg”:”v1.local”}.<token> ?

One of the critical vulnerabilities historically in JOSE implementations was [1], whereby if an implementation was using RSA signed JWTs an attacker could get the server’s public key and use it as if it was a HMAC key to produce a forged JWT with {“alg”:”HS256”} in the header. If the JWT library just provided a verify(String jwt, Key key) function then it might be tricked into using the attacker’s choice of algorithm (HS256) with the server’s RSA public key and the JWT would validate. Oops!

This flaw has been rightly criticised, including by the authors of PASETO. Don’t let the attacker chose the algorithm!

But wait, aren’t PASETO implementations potentially vulnerable to *exactly the same vulnerability*?! If my server is set up to use v2.public (Ed25519) signed PASETO tokens, what is to stop an attacker grabbing my Ed25519 public key (which is a 32 byte value) and using it to create a PASETO token using v2.local? Recall that v2.local takes a 32 byte symmetric key. If the PASETO library just has a function verify(String paseto, Key key) and looks at the header to decide how to process the token, then it will have exactly the same vulnerability that those JOSE libraries had. So how does PASETO the spec make this vulnerability less likely?

Looking at the reference implementation [2], it seems that if the library user didn’t set an allowed purpose then the only thing stopping this is a type check on the public key class. In other words, the implementor took extra safe-guards beyond those documented in the specification. Phew!

Am I missing something here? As far as I can tell, the PASETO docs and draft RFC don’t even mention this as a consideration. How is this better than JOSE?