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

[Eric Rescorla <[e-mail]>]

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

>
> Hiya,
>
> On 18/04/2024 21:13, Eric Rescorla wrote:
> > On Thu, Apr 18, 2024 at 12: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.
> >>
> >
> > As far as I can tell this isn't "blocking the IETF".  This is an
> individual
> > submission,
> > AD sponsorship of individual drafts is entirely at AD discretion, and
> Paul
> > has
> > opted not to sponsor.
>
> I agree it's entirely up to Paul and any AD as to whether
> or not to AD sponsor a document. That wasn't what I was
> asking be clarified.
>
> To be more concrete: I think at one point Paul described the
> crypto panel review as a consensus process which it's not.
>

I don't know enough to have an opinion on this statement.



> The 2nd mis-statement was that an AD should not sponsor
> any document that had received a negative opinion from CFRG,
> which I think oversteps the bounds of IRTF/IETF interactions.
>

This doesn't seem like a misstatement but rather a position you
happen to disagree with. With that said, I think it's entirely
within the realm of discretion of an AD to choose not to sponsor
documents with negative opinions from any group of people
they trust (or, for that matter, to sponsor no documents at all).

Do you have some citation to an IETF document that says otherwise?

-Ekr





>
> I'd hope clarifying these things should be straightforward.
> (And has nothing to do with SSH.)
>
> Cheers,
> S.
>
> >
> > It would obviously be different if there were IETF consensus to form a WG
> > and publish this draft and someone were citing the CFRG as a veto point,
> > but that's not what's happening here.
> >
> > -Ekr
> >
> >
> >>
> >> 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
> >>
> >
>