Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts

[mcgrew <[e-mail]>]

Hi Mike,

Please see inline:

> On Mar 18, 2019, at 4:43 PM, Michael StJohns <[e-mail]> wrote:
> 
> I don't understand - usually when I say "I'm fine with the status quo for now" people stop arguing with me.   Oh well.
> 
> And thanks David for making some points for me.  See below.
> 
> 
> On 3/18/2019 9:26 AM, mcgrew wrote:
>> Hi Mike,
>> 
>> Let me add few data points from a CFRG-historical perspective.  CFRG has been the first publisher of a number of specifications (for instance, XMSS, Poly1305, and HBS are in this category -  https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential review for some ISE-published crypto like UMAC (RFC 4418).
> 
> My point was that becoming a first publisher puts the CFRG into the position of being the standardizer.  XMSS, Poly1305 and HBS (not yet published) are all 2018 and 2019 documents.  EDDSA was 2017.  In fact the set of documents currently attributed to the CFRG only goes back to 2014 while the CFRG has been around a lot longer than that.  Something changed

The RG shifted from discussing and reviewing independent documents towards producing its own documents.  

> and now we're getting standards-like production out of the CFRG.  Note that I don't think its a bad thing per se, just that you need to be following different rules than those that are applicable to RGs.
> 
> For example, why does an informational document in the research stream need a registry?  (e.g. RFC8391)   That's about as obvious a standardization requirement as any I've seen in CFRG documents.

The registry and the interface and extensibility it provides is essential to making a crypto specification future-proof. That is clearly best practice in cryptography, and as such is totally appropriate for the output of an IRTF RG document.   Some independent documents that were reviewed by CFRG also had registries. 

David

> 
>>  For UMAC, it is worth noting that the ISE reviewers asked for changes around IPR language,
> 
> I don't think I even recall seeing anything that wants to use UMAC - I may have missed a protocol or two though.  In any event, the request was to REMOVE claims about IPR language from the document and direct the authors to make a normal IPR disclosure. Again - pretty consistent with what we do with standards and IETF stream documents.
> 
>> and CFRG reviewers made important improvements to the technical content as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail threads from fall 2005).  So the issues we are dealing with today are not really new.
> 
> But again, that's normal for any document that comes in through any stream - specifically - people review it and usually irrespective of association with a specific WG/RG/directorate, etc.  The fact that the document author, the ISE and the IESG reached out the the CFRG is pretty much an example of looking for the experts in a pile of experts.  I'm not sure why this wouldn't happen if the CFRG were chartered as a WG?
> 
> 
>> 
>> You have started a good, healthy discussion with the points that you have raised.  My thinking is that CFRG (including Kenny, Alexy, and the many contributors) is doing really good, really important work, and the IRTF and IETF should avoid changes that would disrupt it.
> 
> I don't want to change the people, I don't even want to change the work flow (much - except that moving it to a WG would actually remove the IRTF from the approval process for an RFC), I just want this to be appropriately categorized and managed as a WG and subject to the same rules as any other WG.   I think its gone well past the normal rules for an RG at this point.
> 
> Again - I've indicated my concerns and I'm happy the discussion is happening.  Unfortunately what I keep hearing is "we like it the way it is, now go and leave us alone" rather than "we're really a RG because we do things X, Y and Z so we really don't need to be a WG".  I'd really like to hear more commentary on that latter - especially how the CFRG in fact differs from the behavior of a WG.
> 
> Thanks - Mike
> 
> 
> 
>> 
>> Best,
>> 
>> David
>> 
>>> On Mar 15, 2019, at 2:52 PM, Michael StJohns <[e-mail]> wrote:
>>> 
>>> On 3/13/2019 7:32 AM, Richard Barnes wrote:
>>>> Mike, are your concerns here primarily IPR related?  If that's so, then maybe that's the level at which we should address them, as opposed to flipping the bigger RG->WG switch.
>>>> 
>>> Hi Richard -
>>> 
>>> Like I said, I'm not going to push this at this time.  But I think its more than just IPR - avoiding technology because of IPR is more a symptom (and in fact is IETF guidance rather than IRTF policy).
>>> 
>>> The CFRG has a unique position in that - unlike ANY other RG as far as I can tell - it's looked at as an immediate feeder for technology for the IETF.  If it were agnostically evaluating the crypto properties of any offered technology, I'd say we're good and I'd move on.  But, with the publication of Curve25519 and its related ... standards ..., the CFRG has moved from evaluation and re-publication of cryptographic standards developed and produced elsewhere into being the first publisher of what could only be characterized as standards, even if published as an Informational RFC in the IRTF stream.
>>> 
>>> Ultimately, I think it comes down to fairness and transparency. As an RG, the publications of the RG are not subject to the standards appeals process.  In an WG, the decision not to work on an IPR encumbered technology (or others such as national cryptography) MAY be appealed and overturned (or might not) or sponsored by an AD if there's no applicable or agreeable WG. There's a process for showing such decisions were made transparently, and with a broader audience than just the CFRG having a say.
>>> 
>>> 
>>> Later, Mike
>>> 
>>> Ps - hmm... Note that the CFRG charter only mentions the IETF and not the IRTF....
>>> 
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/cfrg
> 
>