Re: [saag] CFRG, CFRG crypto review panel and IETF consensus

[Deb Cooley <[e-mail]>]

SSH:  As it happens the SSH draft asked for a code point last year, and it
was approved (in Nov 2023).  We are working to make sure that code point is
visible on the IANA registries.

Where we go from here is dependent on the SSH community's desires.

Deb Cooley
Sec AD

On Thu, Apr 18, 2024 at 3:04 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 18/04/2024 18:18, Watson Ladd wrote:
> > Dear SAAG,
> >
> > I am quite confused about how the relation between IETF work and CFRG
> > work and the crypto review panel is supposed to work. In the SSH
> > NTRUPrime discussion it appears that a negative report from the crypto
> > review panel is reason not to standardize an algorithm choice or
> > register it in the IETF space for a protocol, and that this comes
> > without discussion of the merits and consensus among even the CFRG
> > participants.
>
> I agree the above has been stated as being the case and
> would be hugely problematic. Even a CFRG consensus that
> something is bad ought not by itself be sufficient reason
> to block the IETF, never mind a crypto panel review that
> wasn't a topic of discussion. It's ok that either thing
> is weighed in reaching a conclusion but there should be
> no vetoes.
>
> I think it'd be good if this situation were clarified.
>
> Cheers,
> S.
>
> >
> > I don't recall this being the way things used to work, and I think its
> > had very negative effects on the way the CFRG functions, as well as
> > stretching the IETF/IRTF distinction beyond the breaking point. Simply
> > put having knock out contests like we did for curves and PAKES,
> > combined with an endless series of reviews and last calls creates some
> > very adversarial debates and raises tensions and hampers cooperation.
> > It also moves away from the running code part and rough consensus: if
> > a group of people have made choices that work for them, we now make
> > ourselves irrelevant by saying no rather than trying to accommodate
> > their concerns. The CFRG review panel is not well placed to have these
> > conversations as it knows nothing of the broader context and has very
> > limited interaction with the proposal.
> >
> > It also puts the CFRG into a place where it is making standardization
> > choices that properly being to the IETF, and not even the CFRG but a
> > subpanel. The massive backlog of documents results in part from an
> > extremely lengthy process even after RGLC, which I think results in
> > part from the higher perceived stakes.
> >
> > This isn't to say that we should abandon security examination of
> > proposed algorithms, but it's pretty clear that we have treated
> > cryptographic primitives very differently in ways that undermine core
> > principles of the IETF process.
> >
> > Sincerely,
> > Watson Ladd
> >
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>