Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens
Scott Arciszewski <scott@paragonie.com> Mon, 23 April 2018 19:00 UTC
Return-Path: <scott@paragonie.com>
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 031F712E03C for <cfrg@ietfa.amsl.com>; Mon, 23 Apr 2018 12:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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: 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 LbgB19UBBdhu for <cfrg@ietfa.amsl.com>; Mon, 23 Apr 2018 12:00:05 -0700 (PDT)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 3564F12D952 for <cfrg@ietf.org>; Mon, 23 Apr 2018 12:00:05 -0700 (PDT)
Received: by mail-ot0-x231.google.com with SMTP id v64-v6so18437780otb.13 for <cfrg@ietf.org>; Mon, 23 Apr 2018 12:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragonie-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <9F9C6A42-0E89-4AB9-915C-8B208D9C31FD@gmail.com>
References: <CAKws9z15m6WY+-mz5D01vxB4s-TE7nQN56=ssYt=vz3z4gAj6A@mail.gmail.com> <DBC2F048-C949-4362-8FD0-A43A54767B03@gmail.com> <CAKws9z277JLfv7Pb9wSkJ7zYR8FzoAfiXuFS6Vq0x32-3bWx7Q@mail.gmail.com> <DB58CEFE-ED93-4C1C-9212-B622DFCCFFB9@gmail.com> <A6784DBB-C147-40B7-8A5C-E96F431020F6@tzi.org> <SN6PR00MB0301F595CF57BF58D4BAA4D2F5B40@SN6PR00MB0301.namprd00.prod.outlook.com> <CACf5n78R3Fur_eunfiQnM9+enbV5vrXs8aW1sfmU6HhV6_3WVA@mail.gmail.com> <9F9C6A42-0E89-4AB9-915C-8B208D9C31FD@gmail.com>
From: Scott Arciszewski <scott@paragonie.com>
Date: Mon, 23 Apr 2018 15:00:03 -0400
Message-ID: <CAKws9z2JithtthAkDKQCdFzJDGRCP22j5-R0b+EvBX6J5TmiKg@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Cc: David Adrian <davadria@umich.edu>, Carsten Bormann <cabo@tzi.org>, "cfrg@ietf.org" <cfrg@ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000447d34056a88a5b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/sFWgzYW6koJZXqT0PhF3rC22rEE>
Subject: Re: [Cfrg] [jose] 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 <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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 <https://paragonie.com> On Mon, Apr 23, 2018 at 12:43 PM, Neil Madden <neil.e.madden@gmail.com> wrote: > > > On 23 Apr 2018, at 14:44, David Adrian <davadria@umich.edu> 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] https://auth0.com/blog/critical-vulnerabilities-in- > json-web-token-libraries/ > [2] https://github.com/paragonie/paseto/blob/master/src/Parser.php#L159 > > Neil > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Salz, Rich
- [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcur… Scott Arciszewski
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Neil Madden
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Neil Madden
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Carsten Bormann
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Vladimir Dzhuvinov
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Mike Jones
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… David Adrian
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Neil Madden
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Mike Jones
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Neil Madden
- Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Ag… Scott Arciszewski
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Scott Arciszewski
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Salz, Rich
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Scott Arciszewski
- Re: [Cfrg] RFC Draft: PASETO - Platform-Agnotic S… Salz, Rich