[CFRG] Re: [EXTERNAL] Re: Should CFRG documents define syntax that is not instantiated?

[Christopher Patton <[e-mail]>]

Thanks Rich + Mike for sharing your views! It would be great to hear from
others, but I'm so far satisfied that this feature should stay in the draft.

Chris P.

On Wed, Jul 10, 2024 at 10:11 AM Mike Ounsworth <Mike.Ounsworth=
[e-mail]> wrote:

> I second Rich; “research group” implies that the CFRG is allowed to work
> on things that do not have direct and immediate applications. The CFRG
> charter seems to align with that interpretation.
>
>
>
> My personal view is that documenting a cryptographic construction and the
> security properties that it has is useful input to protocol design. The
> negative case -- that something does not have sufficient security
> properties for any current Internet applications -- is still a useful
> research outcome worth documenting.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Salz, Rich <rsalz=[e-mail]>
> *Sent:* Tuesday, July 9, 2024 9:06 AM
> *To:* Christopher Patton <cpatton=[e-mail]>; CFRG <
> [e-mail]>
> *Subject:* [EXTERNAL] [CFRG] Re: Should CFRG documents define syntax that
> is not instantiated?
>
>
>
> (PPM to BCC) CFRG has done many documents because they were asked to, and
> need for things was anticipated to be quickly used. If circumstances
> change, that is certainly an argument to remove it. On the other hand, CFRG
> is a *research* group,
>
> (PPM to BCC)
>
>
>
> CFRG has done many documents because they were asked to, and need for
> things was anticipated to be quickly used. If circumstances change, that is
> certainly an argument to remove it. On the other hand, CFRG is a *
> *research** group, and I think that would overrule the removal.
>
>
>
> *From: *Christopher Patton <cpatton=[e-mail]>
> *Date: *Monday, July 8, 2024 at 1:38 PM
> *To: *"[e-mail]" <[e-mail]>, ppm <[e-mail]>
> *Subject: *[CFRG] Should CFRG documents define syntax that is not
> instantiated?
>
>
>
> Hi CFRG (cross-posting to PPM for context),
>
>
>
> The VDAF draft defines a DAF ("Distributed Aggregation Function") as a
> VDAF without robustness, e.g., Prio without the validity proof:
>
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vdaf-09#section-4
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-irtf-cfrg-vdaf-09*section-4__;Iw!!GjvTz_vk!TFJIyp07nXdsjNuD-A-JnwzLdaCz3EBskarRZuNkIB8b7SNvqqRBDjl8qkq9GXc0uruAo5BTYpGo07Q_TDPb5T9r0wcW$>
>
>
>
> This was identified early on as a feature one might want in a protocol
> where robustness is achieved by some other means, e.g., by running the
> client in a TEE. So far no one has defined a concrete DAF, and we haven't
> needed this feature in PPM (DAP does not support this today).
>
>
>
> My question for CFRG is whether it's appropriate for a document to define
> syntax that is neither used nor instantiated by an existing document. If
> not, then we should consider removing DAF from the VDAF draft:
>
> https://github.com/cfrg/draft-irtf-cfrg-vdaf/issues/346
> <https://urldefense.com/v3/__https:/github.com/cfrg/draft-irtf-cfrg-vdaf/issues/346__;!!GjvTz_vk!TFJIyp07nXdsjNuD-A-JnwzLdaCz3EBskarRZuNkIB8b7SNvqqRBDjl8qkq9GXc0uruAo5BTYpGo07Q_TDPb5eT1DAoR$>
>
>
>
> Thanks!
>
> Chris P.
>