Re: [jose] An attempt at unlinkable tokens with minimal magic

"Zundel, Brent" <brent.zundel@avast.com> Tue, 02 August 2022 19:18 UTC

Return-Path: <brent.zundel@avast.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 898E9C14CF02 for <jose@ietfa.amsl.com>; Tue, 2 Aug 2022 12:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level:
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=avast.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwFNsweNaNbr for <jose@ietfa.amsl.com>; Tue, 2 Aug 2022 12:18:54 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62704C14CF17 for <jose@ietf.org>; Tue, 2 Aug 2022 12:18:54 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id gk3so15472259ejb.8 for <jose@ietf.org>; Tue, 02 Aug 2022 12:18:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=avast.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+xFjGVDBkDXIJrkJhN4Bk54jRsNYro/z3/cfUMfeWM=; b=fjirIdICn/QUmXrMOZ3F/sBWLA6Z6QnLez+v/D1yNlDNl7+BQz3gL0J4xhxHQNoAYL nYIvn2ZPkd/cd90ylyA9Agf+1fE8ZHWtSfTcQTujr3VWhvKVlM1/pTECr+XL/GQqzdWN eiT4eDanvAJ651r8NyV95KZvqlI1AwfDO8Orc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5+xFjGVDBkDXIJrkJhN4Bk54jRsNYro/z3/cfUMfeWM=; b=1UdYmSxp2znPfG4brPZAxpKBknsH0qo8yMmzE1WjVFxBiyIQZ+oTAFlHYceWldyXGl xFdAfTxHqpvTnP4Dnnlm8lX9Ih5J6gQ84NVZS0HrIOezoveiCXmCC4lOp1rLMkC9i2Vl xbnpFuVvCYVhpaPCxIVLX8ReSsEAASQ6z1E51hjfupNV/2UOIuozuLGZZtd7xm4x3mkh r4WOQrZOFtSpOXbPVID4260GH9xpkdVFj6dhfcjvxRy19BYPTMTAj1MneUptl4BAHHe/ txUvUAulzyzIUDsLC+kvBxuNzokzmw0wLanOaZTiC7hGzl/6isMboeFkaYMBdRleRRf/ mmiA==
X-Gm-Message-State: ACgBeo2dsxIMdKlOH1Dco7wUSfphP5eoYtCQWBhkzaNOulr5bs/f/THI sxWQ6vmT7Mtrin40T0OjrbFYNFxLeFc2WCdw5gXDvw==
X-Google-Smtp-Source: AA6agR4UtyIQOkGOBj12BzApm1EXTK+8SKFWEN4dzEgKv4i5gHS3ZgjwQZ0m9aaBMaqmvsoybPzIiAWU28n87Q6MHzU=
X-Received: by 2002:a17:907:72d1:b0:730:a0c4:2aaa with SMTP id du17-20020a17090772d100b00730a0c42aaamr3345806ejc.560.1659467932385; Tue, 02 Aug 2022 12:18:52 -0700 (PDT)
MIME-Version: 1.0
References: <ME4P282MB0984F3582C4BD1707B86C8068E969@ME4P282MB0984.AUSP282.PROD.OUTLOOK.COM> <3D04F1F0-ACA2-402D-94B5-BB227126CFAE@forgerock.com> <CAAFNpxu0=MEwnUTtgxuU48aJVmFODwu=oLBOwxEevoa=r1iZFw@mail.gmail.com> <FA054BF3-440B-43E8-81B5-42BDADC14498@forgerock.com> <CAN8C-_JD7FjGkiP_SmyWBJpKtM33Fkmm97u9u3v3UM_6MrPr5Q@mail.gmail.com>
In-Reply-To: <CAN8C-_JD7FjGkiP_SmyWBJpKtM33Fkmm97u9u3v3UM_6MrPr5Q@mail.gmail.com>
From: "Zundel, Brent" <brent.zundel@avast.com>
Date: Tue, 02 Aug 2022 13:19:24 -0600
Message-ID: <CAGi82uMvrrnx1KejuAohStKwSdZsr2v5+8U4iu-v7Hz_h0apdA@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: Neil Madden <neil.madden@forgerock.com>, Jeremie Miller <jeremie.miller@gmail.com>, Vasileios Kalos <vasilis.kalos=40mattr.global@dmarc.ietf.org>, jose@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a163fb05e546fc7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/fDW3TmgP3n3X49Cho0lytd-8q1M>
Subject: Re: [jose] An attempt at unlinkable tokens with minimal magic
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 02 Aug 2022 19:18:56 -0000

>  If we are going to do modern cryptography, we will either have a
standard json representation or we won't.

This hits a main point for me. We want to use modern cryptographic schemes,
and would prefer to have a standard JSON representation. None of the
existing JOSE formats work, it looks like JWP would work great, while also
making use of the general architecture shared by other JOSE formats.

On Tue, Aug 2, 2022 at 7:00 AM Orie Steele <orie@transmute.industries>
wrote:

> Good security is about building the right layers.
>
> Many of these arguments might be better focused in the CFRG.
>
> I wonder if the argument in this thread might be some version of denying
> the problem... If we are going to do modern cryptography, we will either
> have a standard json representation or we won't.
>
> If the assertion is, let's not use that cryptography... That's not exactly
> an argument against the envelope format.
>
> I am in favor or resurrecting JOSE and defining JWP.
>
> Regards,
>
> OS
>
>
>
>
>
>
>
> On Tue, Aug 2, 2022, 4:51 AM Neil Madden <neil.madden@forgerock.com>
> wrote:
>
>> On 30 Jul 2022, at 18:26, Jeremie Miller <jeremie.miller@gmail.com>
>> wrote:
>>
>>
>> Isn’t this somewhat overstating the likely privacy benefits? If the
>>> prover reveals _any_ PII to the verifier then the verifier can collaborate
>>> with the issuer to discover everything about that user.
>>>
>>
>> JWP as a container aims to make unlinkability _possible_ for applications
>> to build, not a guarantee.  There are many extremes an application may
>> choose to design for to accomplish different scales of unlinkability (from
>> multiple verifiers colluding, from the verifier and issuer colluding, from
>> multiple presentations to the same verifier, etc).
>>
>> In my mind it's akin to you can cryptographically validate the contents
>> and signature in a JWS, but how you decide if you trust the signer is up to
>> the application or higher level protocols.
>>
>> And we know from many studies on deanonymisation that it is very easy to
>>> accidentally reveal enough information to be identifiable. ZK proofs are
>>> nice and everything but they only ensure zero *additional* knowledge is
>>> gained by the verifier. In practice what is explicitly revealed is often
>>> enough.
>>>
>>
>> That's exactly why we believe this work is very important, having a
>> container to support algorithms where zero *additional* knowledge is
>> revealed by the container and crypto layers.
>>
>> It *is* very easy to incidentally reveal linkable factors, which is why
>> JWP is hard to get right, and critical to do so to enable this capability.
>>
>> IMO if you want to have any hope of actually achieving the privacy you
>>> want then you really need to design the entire protocol, including
>>> specifying exactly what information is to be revealed. I think designing a
>>> generic “privacy preserving” message container is likely to give people
>>> unrealistic expectations.
>>>
>>
>> We have the lowest level privacy algorithms becoming well established
>> like BBS (and CL signatures, etc), next we need a privacy-capable container
>> to make those algorithms more accessible and interoperable, then we need
>> privacy protocols to leverage those containers, then privacy aware
>> applications, ecosystems, and user experiences.
>>
>>
>> I think perhaps we most fundamentally disagree on this roadmap. Although
>> many standardised systems have followed this kind of modular design, I
>> don’t think it is the best approach. Compare say IPSec vs WireGuard for an
>> often-cited example. Privacy is not a separable concern. Start with the
>> privacy-aware applications. Otherwise I think we’ll end up with lots of
>> “privacy-related” tools with lots of sharp edges that inevitably get used
>> inappropriately.
>>
>> — Neil
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>


-- 
Brent Zundel
Principle Crypto Engineer - Avast