Re: [CFRG] Call for adoption: Hybrid KEM Combiners

[Nick Sullivan <[e-mail]>]

Dear CFRG,

The adoption call has ended. There was more than enough support on the list
to adopt, but there was also a lot of discussion about what the community
wants and doesn't want from a document on this topic. Thank you to those
who expressed interest about being part of a design team - we'll be in
touch. We're also still open to hear from last-minute volunteers. We will
reserve some time at IETF 119 for further discussion on this topic.
Thank you to everyone for the input on this thread, it was very
enlightening.

Nick, Stanislav, Alexey

On Thu, Feb 22, 2024 at 1:15 PM Nick Sullivan <[e-mail]>
wrote:

> Dear CFRG,
>
> The three-week adoption call has ended, but given the robust discussion on
> the list, we are extending the adoption call time for two weeks until March
> 6th.
>
> With this extension in mind, we wanted to share our tentative plan for if
> this research topic is adopted. Feedback on the list has been varied, but
> two of the themes that have come up in the discussion are: 1) urgency: some
> participants have expressed a perceived urgency around the timeline of this
> document's publication 2) clarity: the requirements for this document
> should be made clear to the group before writing begins. We are considering
> putting together a small design team, like in other groups, to put together
> requirements to share with the CFRG, potentially at IETF 119, where we
> expect to have an open discussion about the topic.
>
> With this context, we would like to invite participants to continue the
> ongoing discussion. If you are additionally interested in volunteering for
> the design team, or are interested in doing a 5-minute-or-less lightning
> talk at IETF 119 related to this topic, please contact the chairs (
> [e-mail]).
>
> Nick, Stanislav, Alexey
>
> On Wed, Jan 31, 2024 at 10:28 AM Nick Sullivan <
> [e-mail]> wrote:
>
>> Dear CFRG,
>>
>> There has been a lot of discussion on the list over the last few weeks
>> around the topic of hybrid KEMs, including discussion around the topic of
>> where we should go as a group. There seems to be significant interest in
>> this topic from around the IETF and in broader industry. We (the chairs)
>> have decided to open up a research call for adoption for a topic in this
>> area, described below.
>>
>> The standard context for the group applies here as always: As part of the
>> IRTF, the CFRG is a research group, producing research documents relevant
>> to the IETF and broader community. The CFRG does *not* publish standards
>> and does *not* dictate cryptographic choices to IETF working groups.
>> CFRG documents often come with concrete specifications for
>> parameterizations relevant to groups within the IETF. Recent examples of
>> documents of this style resulting from topics adopted by the CFRG include
>> RFC 9497 (OPRF) and RFC 9381 (VRF), which provide a thorough overview of
>> the topic along with concrete parameterizations that can adopted by
>> protocol designers.
>>
>> The CFRG has a full docket of important ongoing work, so it’s important
>> to ensure that any work the CFRG adopts at this point aligns with the
>> charter by offering necessary guidance (for network security in general and
>> for the IETF in particular) on the use of emerging mechanisms.
>>
>> With that preamble done,* this email starts a three-week call for the
>> adoption* of a work item within the CFRG to produce an informational
>> document exploring how to safely combine KEMs. This document
>> * Will use draft-ounsworth-cfrg-kem-combiners as a starting point for
>> describing generic combiners
>> * Will include an analysis of the non-generic combiner mechanisms for
>> specific KEMs outlined in draft-connolly-cfrg-xwing-kem and other published
>> works in the area
>> * Will describe the security properties and trade-offs of various methods
>> of combining KEMs
>> * Will provide concrete instantiations of hybrid KEMs that are relevant
>> to IETF protocols (potentially similar to X-Wing and Chempat-X), including
>> pseudocode and test vectors
>>
>> Please give your views on whether this should be adopted as a CFRG draft
>> and whether you would be willing to work on this document and/or review it.
>>
>>
>> Nick, Alexey, Stanislav
>>
>