[Privacy-pass] Re: Call for adoption: draft-yun-cfrg-arc-01 (Ends 2025-09-30)

[Dennis Jackson <[e-mail]>]

Thank you for the summary of all the progress Cathie, it's exciting to see!

It seems like we're well supplied with expertise to develop this draft 
here knowing we have the CFRG as a backstop prior to WGLC.

Best,
Dennis

On 28/09/2025 23:25, Cathie Yun wrote:
> Thanks for all the support for the adoption of draft-yun-cfrg-arc-01!
> I'd like to provide updates on the status of the draft, and in the 
> process address some feedback from this thread.
>
> 1. We are moving draft-yun-cfrg-arc-01 to use the Interactive Sigma 
> Protocols and Fiat-Shamir Transform specs, as promised!
> I have a PR in flight [1] to move draft-yun-cfrg-arc-01 to 
> use the Interactive Sigma Protocols and Fiat-Shamir Transform specs 
> [2, 3]. This will allow us to remove the entire "Schnorr Compiler" 
> section of draft-yun-cfrg-arc-01 (section 5.1 of [4]), offloading a 
> lot of the cryptographic complexity of the draft to those specs, which 
> have been adopted by the CFRG. (This also addresses the typos/bugs 
> Eli-Shaoul found in section 5.1 - thanks for the careful review). The 
> PR just hasn't been finalized yet because there are some API changes 
> in-flight for the Fiat-Shamir Transform spec, which are blocking - we 
> are actively working on that [5].
>
> 2. We are adding nonce hiding to draft-yun-cfrg-arc-01!
> I mentioned in a previous email to the privacy pass group [6] that we 
> have had great progress with making an arbitrary-range range proof, 
> which is simple and straightforward to standardize. With the help of 
> the community (many thanks to Chris P, Lena, Michele, Jonathan, Sam, 
> Watson and Ian), that has come together nicely and we now have a draft 
> for a range proof in ARC, which is under review [7]! Once that is 
> approved, we will use that range proof to hide the nonce used in ARC 
> tags. This will solve the privacy leakage in the situation where the 
> verifier sees two presentations with the same nonce but different tags 
> (with the same presentation context), and therefore knows the two 
> presentations must have been created from different credentials.
>
> 3. Comparative benchmarks between ARC and privacy pass "batched" 
> proofs (for RSA blind signatures)
> During my presentation at IETF123, the question of "what's the 
> breakeven point between ARC and privacy pass batched proofs" came up. 
> I've been working with Raphael Robert to get comparative benchmarks - 
> this is a bit difficult, as it depends on curve type / security 
> parameters, as well as having comparatively-optimized and 
> interoperable implementations. Furthermore, the ARC verification cost 
> will be affected by the nonce hiding proof, which we haven't finished 
> yet. I'll keep this group posted once we have more concrete numbers!
>
> [1] https://github.com/chris-wood/draft-arc/pull/37
> [2] https://datatracker.ietf.org/doc/draft-irtf-cfrg-sigma-protocols/
> [3] https://datatracker.ietf.org/doc/draft-irtf-cfrg-fiat-shamir/
> [4] https://datatracker.ietf.org/doc/draft-yun-cfrg-arc/
> [5] https://github.com/mmaker/draft-irtf-cfrg-sigma-protocols/pull/79
> [6] 
> https://mailarchive.ietf.org/arch/msg/privacy-pass/9q9_GAHJoXWWkPKJyBjXKmbMI3g/
> [7] https://github.com/chris-wood/draft-arc/pull/38
>
> Many thanks,
> Cathie Yun
>
> P.S. Eli-Shaoul's observation that the definition of RandomScalar() is 
> inconsistent in different places was a great catch. It should always 
> return a non-zero scalar. This mistake actually exists in the 
> (finalized) OPRF spec (https://datatracker.ietf.org/doc/rfc9497/) 
> which is where I copied the boilerplate from! Chris Wood said he will 
> open an errata to fix this in the OPRF spec, and I have fixed it in 
> the ARC spec. Thanks for pointing this out!
>
> On Tue, Sep 16, 2025 at 7:08 AM Thibault Meunier 
> <ot-ietf=[e-mail]> wrote:
>
>     I support adoption of this draft, assuming it undergoes a full
>     review by the Crypto Panel [1] as mentioned in the adoption call.
>
>     [1] https://wiki.ietf.org/group/cfrg/CryptoPanel
>
>
>     I would not have the crypto expertise to review it in-depth, but
>     trust that people in the group would, and am interested in its use
>     cases such as draft-yun-privacypass-arc.
>
>     Thibault
>     On Wednesday, September 10th, 2025 at 7:04 PM, Christopher Patton
>     <cpatton=[e-mail]> wrote:
>
>     > I support adoption and am willing to review.
>     >
>     > The draft is already in pretty good shape. My feeling is that
>     the main work left to do is to align with the sigma protocols
>     draft and to work out how to hide the nonce. We're currently
>     working on the latter, and the former has a pretty clear path.
>     >
>     > Great work so far Cathie and Chris!
>     >
>     > Best,
>     > Chris p.
>     >
>     > On Tue, Sep 9, 2025 at 8:37 AM Benjamin Schwartz via Datatracker
>     <[e-mail]> wrote:
>     >
>     > >
>     > > Subject: Call for adoption: draft-yun-cfrg-arc-01 (Ends
>     2025-09-30)
>     > >
>     > > This message starts a 3-week Call for Adoption for this document.
>     > >
>     > > Abstract:
>     > > This document specifies the Anonymous Rate-Limited Credential
>     (ARC)
>     > > protocol, a specialization of keyed-verification anonymous
>     > > credentials with support for rate limiting. ARC credentials can be
>     > > presented from client to server up to some fixed number of times,
>     > > where each presentation is cryptographically bound to client
>     secrets
>     > > and application-specific public information, such that each
>     > > presentation is unlinkable from the others as well as the original
>     > > credential creation. ARC is useful in applications where a server
>     > > needs to throttle or rate-limit access from anonymous clients.
>     > >
>     > > File can be retrieved from:
>     > > https://datatracker.ietf.org/doc/draft-yun-cfrg-arc/
>     > >
>     > > Please reply to this message keeping [e-mail] in
>     copy by
>     > > indicating whether you support or not the adoption of this
>     draft as a WG
>     > > document. Comments to motivate your preference are highly
>     appreciated.
>     > >
>     > > Authors, and WG participants in general, are reminded of the
>     Intellectual
>     > > Property Rights (IPR) disclosure obligations described in BCP
>     79 [2].
>     > > Appropriate IPR disclosures required for full conformance with
>     the provisions
>     > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware
>     of any.
>     > > Sanctions available for application to violators of IETF IPR
>     Policy can be
>     > > found at [3].
>     > >
>     > > Thank you.
>     > > [1] https://datatracker.ietf.org/doc/bcp78/
>     > > [2] https://datatracker.ietf.org/doc/bcp79/
>     > > [3] https://datatracker.ietf.org/doc/rfc6701/
>     > >
>     > >
>     > >
>     > > --
>     > > Privacy-pass mailing list -- [e-mail]
>     > > To unsubscribe send an email to [e-mail]
>
>     -- 
>     Privacy-pass mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>