Re: [Cfrg] would it be a good idea for CFRG to try review algorithm documents?

[Simon Josefsson <[e-mail]>]

Björn Edström <[e-mail]> writes:

> Hi Phillip.
>
> I share your worry and I agree. Avoid crypto reviews, and try to avoid
> issuing RFC:s for constructs that do not have thorough academic
> review.

...and has support among network security implementers in the global
Internet community.  The CFRG does not live in a vacuum, there should be
demand for what it publishes.  There are constructs with plenty of
academic reviews that are completely pointless to publish through the
CFRG.

/Simon

> However, I don't see drafts using constructs being sanity checked by
> CFRG as giving them a "seal of approval". I see it as a filter to
> prevent accidents (as in the scenario I wrote in my email).
>
> So to clarify, both of these would be bad:
>
> *) An RFC is issued for a construct that is obviously broken to CFRG.
> It was not run by CFRG.
> *) An RFC is issued for a construct that has not been thoroughly
> researched. It's run by CFRG and that is seen as the RG giving a "seal
> of approval" (which is not the case).
>
> Both of those would hurt trust in the process, so it has to be handled
> delicately.
>
> Thoughts?
>
> Best
> Björn
>
>
>
> On Fri, Dec 11, 2015 at 5:29 AM, Phillip Hallam-Baker
> <[e-mail]> wrote:
>>
>>
>> On Wed, Dec 9, 2015 at 8:38 PM, Stephen Farrell <[e-mail]>
>> wrote:
>>>
>>>
>>> Hiya,
>>>
>>> The IESG has another of those conflict reviews on Dec 17. In this
>>> case I doubt there's a process conflict (see below for details)
>>> as this is documenting some more details of the GOST suite which,
>>> as a national algorithm suite, kind of just is what it is.
>>>
>>> But as a non-cryptographer, I'd be happier if in future things
>>> like this (or non-national "vanity" algorithm descriptions) had
>>> gotten some review from CFRG, however I'm not sure if folks here
>>> would be generally willing to do that kind of review.
>>>
>>> The reason I'd like review is so that we have a better idea of any
>>> issues or caveats or cautions when/if the proponents of such
>>> algorithms come calling at the IETF's door for code points to
>>> use their algorithm in TLS/IPsec or whatever. (Which they usually
>>> do do.)
>>>
>>> If this was done informally and we got prompt and good reviews I
>>> think that'd be a fine thing, but if we try formalise it, then we
>>> might end up with some tricky process issues. And I'm not sure if
>>> folks here would be willing to do such reviews or able to get them
>>> done when needed (there aren't too many drafts like this but they
>>> do come along now and then in a reasonably constant dribble).
>>
>>
>> I would prefer that neither the IETF nor the IRTF did any crypto reviews and
>> no RFCs were issued or needed unless it was for an algorithm to be used as
>> RECOMMENDED or REQUIRED.
>>
>> The rationale for this is that regardless of what status IETF considers a
>> document to have, outsiders naturally assume that every RFC is an IETF
>> recommendation. Trying to teach the world otherwise is futile.
>>
>> While some protocols do have limited code points available, it is almost
>> certainly possible to extend these by allocating a code point for and
>> extension scheme. And I would use OIDs for the extension scheme rather than
>> IANA issued identifiers to further distance IETF.
>>
>> Either review thoroughly or not at all. Leading people to think the
>> algorithm has been reviewed when it has not is only going to lead to tears.
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg