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

[Eli-Shaoul Khedouri <[e-mail]>]

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=
[e-mail]> wrote:

> I support the adoption of these two drafts as WG items.
>
> Aykut
>
>
> On Tue, Feb 20, 2024 at 3:04 PM David Schinazi <[e-mail]>
> 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=
>> [e-mail]> 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 <[e-mail]>
>>> 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
>>>>    <https://datatracker.ietf.org/doc/draft-hendrickson-privacypass-geo-extension/>,
>>>>    expiration-extension
>>>>    <https://datatracker.ietf.org/doc/draft-hendrickson-privacypass-expiration-extension/01/>
>>>>    - Partially Blind RSA draft at CFRG:
>>>>    draft-amjad-cfrg-partially-blind-rsa-02.html
>>>>    <https://www.ietf.org/archive/id/draft-amjad-cfrg-partially-blind-rsa-02.html>
>>>>
>>>>
>>>> Best,
>>>> Thibault
>>>>
>>>> On Monday, 19 February 2024 at 17:56, Tommy Pauly <tpauly=
>>>> [e-mail]> 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=
>>>> [e-mail]> wrote:
>>>>
>>>> -extra aliases.
>>>> ------------------------------
>>>> *From:* Ben Schwartz <[e-mail]>
>>>> *Sent:* Tuesday, January 30, 2024 2:21 PM
>>>> *To:* IETF Secretariat <[e-mail]>;
>>>> [e-mail] <
>>>> [e-mail]>;
>>>> [e-mail] <[e-mail]>;
>>>> [e-mail] <[e-mail]>
>>>> *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 <[e-mail]> on behalf of IETF
>>>> Secretariat <[e-mail]>
>>>> *Sent:* Tuesday, January 30, 2024 2:12 PM
>>>> *To:* [e-mail] <
>>>> [e-mail]>;
>>>> [e-mail] <[e-mail]>;
>>>> [e-mail] <[e-mail]>
>>>> *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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>> --
>>>> Privacy-pass mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>>
>>>>
>>>>
>>>> --
>>>> Privacy-pass mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>>
>>>
>>>
>>> --
>>>
>>>  Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |  Cambridge,
>>> MA
>>> --
>>> Privacy-pass mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>
>> --
>> Privacy-pass mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>