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

["StJohns, Michael" <[e-mail]>]

Sorry for the top post - it’s hard to get a coherent edit using an iPad.

Basically, you’ve confirmed what I said - that the CFRG is doing standards
like stuff, and that it just chose to do so.  I note that the change in
behavior was not accompanied by a change in the charter.  I’d expect that
going through a recharterng exercise to bring in line the documentation
with the group behavior would lend more credence to the idea that the
charter should be written for a WG.

WRT the registry - registries are usually created as a result of a
standards action and I was quite surprised to find that this one had been
created.  You used the phrase “make the specification future proof” which
again is more IETF than IRTF IMHOand suggests that the IETF should have
change control.

Later, Mike




On Tue, Mar 19, 2019 at 14:23 mcgrew <[e-mail]> wrote:

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