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

[Stephen Farrell <[e-mail]>]

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.
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.

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
>>
>