Re: [Privacy-pass] The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption By WG Issued"

Thibault Meunier <ot-ietf@thibault.uk> Mon, 26 February 2024 13:35 UTC

Return-Path: <ot-ietf@thibault.uk>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0858C14F71F for <privacy-pass@ietfa.amsl.com>; Mon, 26 Feb 2024 05:35:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=thibault.uk
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 B165jVWOGf7f for <privacy-pass@ietfa.amsl.com>; Mon, 26 Feb 2024 05:35:28 -0800 (PST)
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B1024C14F6F3 for <privacy-pass@ietf.org>; Mon, 26 Feb 2024 05:35:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thibault.uk; s=protonmail; t=1708954524; x=1709213724; bh=bYvP87SNGCIbav0e2A7jQ4CHagREOzyGNDikxMUWq6Q=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=FCZKuai0Qq0AoOcV6p+3XTwok8BAVgnAcMJ5/kj9fLxaW3Pe4KAm8iZ5oAdVRLH6y Z9hwwIzW4+p8YJF1kpLDKIKrOjOXYwMeFOZ2x40tlZP2KzgS4zKErbf0OWS0XJW0EZ pqVwoixQKy0gYKcyDzIna9cGGePvvTAIdMBozsYY=
Date: Mon, 26 Feb 2024 13:34:37 +0000
To: Eli-Shaoul Khedouri <eli=40intuitionmachines.com@dmarc.ietf.org>
From: Thibault Meunier <ot-ietf@thibault.uk>
Cc: Aykut Bulut <aykutb=40google.com@dmarc.ietf.org>, privacy-pass@ietf.org
Message-ID: <9wLbosdAYtY0mNdmlrPp2U74tRVUf3_5o2t6RklgmKjCk3KxoyF78jPR7B8B3BiHMXMauKIfR2HqnX3sHg31Yro0gASUezqHm_H9Mu-gG68=@thibault.uk>
In-Reply-To: <CA+AE54efErWqJrF5JEXRND674pZ5i7GuB32-sWS9cVY+Ln9RYQ@mail.gmail.com>
References: <170664197290.48538.11458873071334659518@ietfa.amsl.com> <SA1PR15MB437035BCB976667A27F13212B37D2@SA1PR15MB4370.namprd15.prod.outlook.com> <SA1PR15MB4370AC2E72FD41FA8277F9DFB37D2@SA1PR15MB4370.namprd15.prod.outlook.com> <F235DBE1-19B7-4738-BCEF-D2E4911206BD@apple.com> <V0hOXeWZP7Z3xxD5m4oK4ROqOtCUSG9JyxkMcpSwhrLLTxyEN-ZdfP1rC-ER87due5C6zv47H-wkPkowuvk-lEQJk53mfl57rKiHoggSI9c=@thibault.uk> <CANduzxBX63BzUa4Y8vtRkkhs+5wXUf2a_Vnt3+yvksjBcRfQrA@mail.gmail.com> <CAPDSy+5Ty1aYkaKTq1TCQ16L7q3dsZMUUuM0h1RzGesBVFzWnw@mail.gmail.com> <CACOcZTjz8a8h1sjMxjuEoTcnvJ94DWfKNq4eRGTXAB=xGL14LA@mail.gmail.com> <CA+AE54efErWqJrF5JEXRND674pZ5i7GuB32-sWS9cVY+Ln9RYQ@mail.gmail.com>
Feedback-ID: 60844204:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_dsoSkMtfDxB8uUURQHodfhEc9CPOUmNvRwrQXqazas"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/n7XE8ShwfdcxYL_GExlYIGh6t8I>
Subject: Re: [Privacy-pass] The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption By WG Issued"
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Pass Protocol <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2024 13:35:31 -0000

I support the adoption of these two drafts by the group. They define PrivateToken extensions auth scheme parameter, as well as two new token types which nicely augment the existing 0x001 and 0x0002, with metadata.

Regarding draft-hendrickson-privacypass-public-metadata specifically, I think bringing concrete extension definitions would foster discussion and better inform the protocol design. In addition, providing working implementation could help build these use cases, which the draft does not link to at the moment.

I've added some comments about both drafts on GitHub, and look forward to review them as they evolve.

Thibault

On Thursday, 22 February 2024 at 18:32, Eli-Shaoul Khedouri eli=40intuitionmachines.com@dmarc.ietf.org wrote:

> Some typos here, but nothing that changes the intent. PR has been opened.
> I support adoption of these items. We (hCaptcha) have brought up this topic several times over the years, as one bit is not sufficient in many applications.
>
> There is not much benefit to preventing the token from affirming coarse details otherwise expressed by the client, e.g. those contained in a user agent string transmitted in parallel.
>
> One item not covered in the drafts: is it worth introducing a revocation concept for extensions at this stage?
>
> Eli
>
> On Thu, Feb 22, 2024 at 10:52 AM Aykut Bulut aykutb=40google.com@dmarc.ietf.org wrote:
>
>> I support the adoption of these two drafts as WG items.
>>
>> Aykut
>>
>> On Tue, Feb 20, 2024 at 3:04 PM David Schinazi dschinazi.ietf@gmail.com wrote:
>>
>>> Hi there,
>>> I'm supportive of adoption of both documents. Over at Google we're working towards deploying our IP Protection feature to all Chrome users, and that relies heavily on public metadata. So we'll have folks reviewing and implementing these. I agree with Tommy that this will require privacy analysis, but we can perform that analysis as a WG before WGLC - it doesn't need to gate adoption.
>>>
>>> David
>>>
>>> On Tue, Feb 20, 2024 at 7:08 AM Steven Valdez svaldez=40google.com@dmarc.ietf.org wrote:
>>>
>>>> I support the adoption of these two drafts as WG items. I think having support for some kind of metadata will be critical for a number of applications of privacypass tokens.
>>>> For the sake of having a possible extension for the WG to build around, it may also be worth trying to adopt either one of the extension drafts or coming up with another extension with WG support. Maybe some time at 119 can be spent on either figuring out next steps for those?
>>>>
>>>> It would also be good to see if there are other crypto primitives that could be used to provide the metadata capability, but using partially blind RSA as a starting point seems reasonable for privacypass (though that draft should probably get some more reviews from the CFRG).
>>>>
>>>> On Mon, Feb 19, 2024 at 12:10 PM Thibault Meunier ot-ietf@thibault.uk wrote:
>>>>
>>>>> I'm currently going over the two documents (and the associated cfrg draft) about Privacy Pass with metadata.
>>>>>
>>>>> During the review, I've found these additional documents helpful:
>>>>>
>>>>> - Two possible extensions for the registry created in draft-wood-privacypass-auth-scheme-extension: geo-extension, expiration-extension
>>>>> - Partially Blind RSA draft at CFRG: draft-amjad-cfrg-partially-blind-rsa-02.html
>>>>>
>>>>> Best,
>>>>> Thibault
>>>>>
>>>>> On Monday, 19 February 2024 at 17:56, Tommy Pauly tpauly=40apple.com@dmarc.ietf.org wrote:
>>>>>
>>>>>> The core privacy pass architecture talks about metadata-supporting token types, so overall I think the WG needs to say something in this space.
>>>>>> Looking at the two documents here:
>>>>>>
>>>>>> - draft-wood-privacypass-auth-scheme-extensions is a very minimal and reasonable mechanism. Assuming that we have drafts (like the other one) that will use it, I support adopting this document as the starting place for allowing the auth scheme to support extensions.
>>>>>>
>>>>>> - draft-hendrickson-privacypass-public-metadata, for an approach to adding metadata, also seems like a nice minimal approach. In general, I’m still concerned about metadata and the implication on privacy analysis. I think the document will need to say a lot more on what kind of metadata would be safe, how to guarantee consistency, and how to not allow the metadata to become a way to identify a single client across the issuance and redemption contexts. For example, if the metadata item is something that the client already is sharing with both the issuance and redemption contexts, and knows will be visible to everyone already, then adding the metadata doesn’t leak any additional state. However, if this is not the case, then it may be risky to reveal information to the issuance path that would otherwise not be visible. Providing some very concrete examples of what metadata can be would help immensely in the discussion.
>>>>>>
>>>>>> So, for this one, I am provisionally supportive of adoption if we can better articulate the bounds on usage and some clear cases that we can agree are admissible.
>>>>>>
>>>>>> As a nit on draft-hendrickson-privacypass-public-metadata: it uses the Blind(), BlindSign(), and Finalize() functions from RSA Blinding with extra parameters for the extensions that aren’t defined in the main RSA Blinding spec. Are these concatenations, or just cases of running the functions twice?
>>>>>>
>>>>>> Thanks,
>>>>>> Tommy
>>>>>>
>>>>>>> On Jan 30, 2024, at 11:28 AM, Ben Schwartz bemasc=40meta.com@dmarc.ietf.org wrote:
>>>>>>>
>>>>>>> -extra aliases.
>>>>>>>
>>>>>>> From: Ben Schwartz bemasc@meta.com
>>>>>>> Sent: Tuesday, January 30, 2024 2:21 PM
>>>>>>> To: IETF Secretariat ietf-secretariat-reply@ietf.org; draft-wood-privacypass-auth-scheme-extensions@ietf.org draft-wood-privacypass-auth-scheme-extensions@ietf.org; privacy-pass@ietf.org privacy-pass@ietf.org; privacypass-chairs@ietf.org privacypass-chairs@ietf.org
>>>>>>> Subject: Re: [Privacy-pass] The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption By WG Issued"
>>>>>>>
>>>>>>> Hi PRIVACYPASS,
>>>>>>>
>>>>>>> draft-hendrickson-privacypass-public-metadata and
>>>>>>> draft-wood-privacypass-auth-scheme-extensions have a mutual normative dependency, so (as previously discussed) the chairs have put them forward for a joint adoption call. We hope that 3 weeks will be enough time for everyone to read both drafts and comment on their suitability for adoption.
>>>>>>>
>>>>>>> If you support or oppose adoption, please comment in this thread.
>>>>>>>
>>>>>>> --Ben Schwartz
>>>>>>>
>>>>>>> From: Privacy-pass privacy-pass-bounces@ietf.org on behalf of IETF Secretariat ietf-secretariat-reply@ietf.org
>>>>>>> Sent: Tuesday, January 30, 2024 2:12 PM
>>>>>>> To: draft-wood-privacypass-auth-scheme-extensions@ietf.org draft-wood-privacypass-auth-scheme-extensions@ietf.org; privacy-pass@ietf.org privacy-pass@ietf.org; privacypass-chairs@ietf.org privacypass-chairs@ietf.org
>>>>>>> Subject: [Privacy-pass] The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions in state "Call For Adoption By WG Issued"
>>>>>>>
>>>>>>> !-------------------------------------------------------------------|
>>>>>>> This Message Is From an External Sender
>>>>>>>
>>>>>>> |-------------------------------------------------------------------!
>>>>>>>
>>>>>>> The PRIVACYPASS WG has placed draft-wood-privacypass-auth-scheme-extensions
>>>>>>> in state Call For Adoption By WG Issued (entered by Benjamin Schwartz)
>>>>>>>
>>>>>>> The document is available at
>>>>>>> https://datatracker.ietf.org/doc/draft-wood-privacypass-auth-scheme-extensions/
>>>>>>>
>>>>>>> Comment:
>>>>>>> Joint adoption call for draft-hendrickson-privacypass-public-metadata and
>>>>>>> draft-wood-privacypass-auth-scheme-extensions.
>>>>>>>
>>>>>>> --
>>>>>>> Privacy-pass mailing list
>>>>>>> Privacy-pass@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>>>>>
>>>>>>> --
>>>>>>> Privacy-pass mailing list
>>>>>>> Privacy-pass@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>>>
>>>>> --
>>>>> Privacy-pass mailing list
>>>>> Privacy-pass@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>>
>>>> --
>>>>
>>>> Steven Valdez |
>>>>
>>>> Chrome Privacy Sandbox |
>>>>
>>>> svaldez@google.com |
>>>>
>>>> Cambridge, MA
>>>>
>>>> --
>>>> Privacy-pass mailing list
>>>> Privacy-pass@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>
>>> --
>>> Privacy-pass mailing list
>>> Privacy-pass@ietf.org
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
>> --
>> Privacy-pass mailing list
>> Privacy-pass@ietf.org
>> https://www.ietf.org/mailman/listinfo/privacy-pass