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

Scott Arciszewski <> Mon, 23 April 2018 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 031F712E03C for <>; Mon, 23 Apr 2018 12:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 LbgB19UBBdhu for <>; Mon, 23 Apr 2018 12:00:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3564F12D952 for <>; Mon, 23 Apr 2018 12:00:05 -0700 (PDT)
Received: by with SMTP id v64-v6so18437780otb.13 for <>; Mon, 23 Apr 2018 12:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2opw8Hk2b519XzwyzrTEqLRjTTTK5IGWtxlc/nbXapg=; b=OI+gUoVsDhittLPjHIczlPGBq2qALWrCrmg6XoYoFY8d2DNYPb+Bm/FhxGcaXh+cOE BAluzZSVbFu6mYgQ5bsEixyAy1Ws1WOQO7PCstyfG/FqE2RvEVjemlTSXMwoB4yT5bsN 06PTe6aLrpAs8vYeAMBIkmw0b/vU58vfnE+mOlPvBakrzGPXP3L3mClE0/FYW6usaetY maneyzdlkkfQ9z3B3WsXllKLqxa6Q9vx0GwecCyYIS65PvTVvQgt5IXGIzcjxHJDqocN nVW98EDUu4IUF9HYL1K/ARGDfRNpSP/GM3XSyav2bHYTxWIN3QyBjkVBweQPWNH3V1H/ 4mfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2opw8Hk2b519XzwyzrTEqLRjTTTK5IGWtxlc/nbXapg=; b=MInIvTmoN3pEcTjtUK2dPvH11t7MeI7qPtUMWjzQnTgvK0QI/ZJxitQbgfdvRU0mcf XbNpamNDGdBQss/NzICqBJnWHjrtFsTu0qcWnVsVCgsVnu+BuzkGL7ySaffRI+CsMg0l SdLxOKtiX6+gmfb2YR071+78wmnvAQjNM7CrLeg+x/F0m9Kcdm8ikjWS4CCJnUsFkkDv QZwETfJI7+55r3F4iUrX5M6Fn03YkVcoNdWTBk+1cqNB+yunBiQVdkvqMGtPtKj7iHwc 83RCH1YZGXh28KtbobarCwruCN4udCP4F1oaDg7kj3BNuluUMiSs6hxAMNqZIDuj/SwV fXGg==
X-Gm-Message-State: ALQs6tAJYkGKrHJA407hbwTGKTpdO5nTLHsdeqkCq7c05eQI5f3+0YJY +fkofY+DBTqs9tXv4XEcsCcdHgBGft5aZ3kuSqG+NgTO
X-Google-Smtp-Source: AIpwx495BOc700eG78D6f9+jiuZAe9KwE1XTj9/Gyda9nKnw5mAZPWEBJYIcxy6cuQq3PED/f7f7kP7ePvN/90KOghU=
X-Received: by 2002:a9d:440b:: with SMTP id u11-v6mr13410255ote.276.1524510004372; Mon, 23 Apr 2018 12:00:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:55e9:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 12:00:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Scott Arciszewski <>
Date: Mon, 23 Apr 2018 15:00:03 -0400
Message-ID: <>
To: Neil Madden <>
Cc: David Adrian <>, Carsten Bormann <>, "" <>, Mike Jones <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000447d34056a88a5b0"
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 19:00:09 -0000

This is an excellent point that will be rectified in the documentation and
future drafts of the RFC.

How is this better than JOSE? It's better in that it's a first draft, not a
final specification. :P

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <>

On Mon, Apr 23, 2018 at 12:43 PM, Neil Madden <>

> > 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?
> [1]
> json-web-token-libraries/
> [2]
> Neil
> _______________________________________________
> jose mailing list