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

[Stephen Farrell <[e-mail]>]

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
>