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

Orie Steele <orie@transmute.industries> Tue, 02 August 2022 13:00 UTC

Return-Path: <orie@transmute.industries>
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 694A5C13CCE8 for <jose@ietfa.amsl.com>; Tue, 2 Aug 2022 06:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
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 8h7vzzDU_hUm for <jose@ietfa.amsl.com>; Tue, 2 Aug 2022 06:00:36 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 95E6DC14CF05 for <jose@ietf.org>; Tue, 2 Aug 2022 06:00:36 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id h28so7140865pfq.11 for <jose@ietf.org>; Tue, 02 Aug 2022 06:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLntmV5ygezeZqPnZeNbeNeZxgASuTJOlg2Pe73r8cc=; b=JM3jrDJ8E6t9gSwB0Z+rHhgarQVAYif16LzlvvJiqMs75wj59SyDYS/USBm6S2t5hv ZFBG/Tv5TxT5d0ENe9l1fUTZnAbPUW1hN1qjZltFRBh5HCNoHBtItTK87W3BR19U8KW6 lFAzRppG3nrIlpOZ71aOeNoJJN+DNdIHe6JGo7YPD2uhclzu3HDcBQ+j8OXsWLUQi4yX xA1/KMjBe5SJ/P2l8gknUjklZTFQIKUN5o5AZEnMzvsBaODMOI0vaH3uIu9DMDIEtm4B FQVUMpOC1VaN4lmozlo0GturAbk2xNv2oU+cKERctoSNJvc3CQuvJVpJRiEt0TxLGQSF 2NCA==
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=oLntmV5ygezeZqPnZeNbeNeZxgASuTJOlg2Pe73r8cc=; b=2+U6NVNCBsRSL39X4s6T5jcKJSDGbTvg/WM5I0aVDfzzsonf9JSZMdiIm+OYWY1MzW 1bH15H8WSzXng4q1J991nqShkIAOk6PqXeiNCzLULrEjKUV5ICTSqwhFq9F8JpiRhQeF M1tKUc9+q/pMrUTKmn5ZnuEAfj/S/UO9Ejljv1ADxE4s5OcktIpZ1USrZrS1OpeHJS4Q MRTSGz+tRLyGkdUv6xZeqyGks1PFQIJvpmn6va50XRGH2ccJPSLSXOuLFILdYBkYabpf AiwgVqpYXFyLgwqXdNHbye5nN84BGV7mcSpBvvPBFmb1Kf+YSzXFXFDZC8oHAkW0NBOo 4sFg==
X-Gm-Message-State: ACgBeo0+FzY9uliXoj+Sm1dhVjnlldE1n1zpGvJvhx05ySgo3V/PB9IC C0MugPHcObhPOxuhkI6LHn3OPl4ofmrYtDPv/hbBvw==
X-Google-Smtp-Source: AA6agR67FAvMFDQ3d8bH+kL73AB0PW9Mjbsgdo2GlUDmv3wM5FTj6pHpCV6Dhlu6LLLmzKFWl51vGc3HT1oH7NrKnzw=
X-Received: by 2002:a62:1a56:0:b0:52d:4352:3ae0 with SMTP id a83-20020a621a56000000b0052d43523ae0mr12022147pfa.35.1659445235372; Tue, 02 Aug 2022 06:00:35 -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>
In-Reply-To: <FA054BF3-440B-43E8-81B5-42BDADC14498@forgerock.com>
From: Orie Steele <orie@transmute.industries>
Date: Tue, 02 Aug 2022 08:00:23 -0500
Message-ID: <CAN8C-_JD7FjGkiP_SmyWBJpKtM33Fkmm97u9u3v3UM_6MrPr5Q@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Jeremie Miller <jeremie.miller@gmail.com>, Vasileios Kalos <vasilis.kalos=40mattr.global@dmarc.ietf.org>, jose@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c772e905e541b3cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/M517lW_ENWoNat8zzDoGPJwZ4Rw>
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 13:00:41 -0000

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
>