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

Big +1 here.  It's not broke, so let's not fix it, especially for purely
process-wonk reasons.

On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <john.mattsson@ericsson.com>
wrote:

> I think it is much more important that CFRG stays a Research Group, than
> it is that CFRG can produce standards track documents. CFRG is unique and
> fills a very important roll. The fact that CFRG documents are used so much
> indicates to me that CFRG is working very well. I would be very hesitant in
> changing something that works.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Cfrg <cfrg-bounces@irtf.org> on behalf of "Blumenthal, Uri - 0553
> - MITLL" <uri@ll.mit.edu>
> *Date: *Monday, 11 March 2019 at 00:39
> *To: *"StJohns, Michael" <msj@nthpermutation.com>
> *Cc: *secdir <secdir@ietf.org>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian
> Farrel)" <rfc-ise@rfc-editor.org>
> *Subject: *Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re:
> [secdir] ISE seeks help with some crypto drafts
>
>
>
> I do not think CFRG should move to become a part of the IETF.
>
>
>
> While (some of) the CFRG-produced documents may be de-facto standards,
> they aren't of the kind that IETF is expected to define, and deal with
> somewhat different things.
>
> Regards,
>
> Uri
>
>
>
> Sent from my iPhone
>
>
> On Mar 10, 2019, at 18:46, StJohns, Michael <msj@nthpermutation.com>
> wrote:
>
> I’ve been wondering for a while now whether it’s time to move the CFRG
> over to the IETF as a working group.  Stephen’s comment on routing stuff
> directly to the CFRG suggests to me that it’s probably time or RSN.
>
>
>
>    In recent years, the CFRG has produced documents that are for lack of a
> better phrase de facto standards.  The rate of document production of the
> CFRG mimics more closely that of a WG than the other extant RGs AFAICT.
> As an RG the CFRG isn’t permitted to publish standards track documents, nor
> is the IESG or the ISE permitted or constrained to require a conflict
> review on the documents the CFRG does produce.  [the latter comment is my
> understanding of the rules of the research stream - it may be flawed, but
> the purpose of RGs is supposed to be looking at futures and that by
> definition shouldn’t be conflicting with the nows].
>
>
>
> An alternative might be to charter a crypto standards WG and try to keep
> the CFRG focused on years out - say how the heck do we deal with the
> quantum apocalypse?
>
>
>
> Or keep the math in CFRG and the on the wire specs for using in a WG.
>
>
>
>
>
>
>
> Discuss!
>
>
>
> Mike
>
>
>
> On Sun, Mar 10, 2019 at 17:48 Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>
> Hiya,
>
> On 10/03/2019 20:57, Tony Arcieri wrote:
> >
> > I think there are significant compelling reasons to prefer OCB mode
> > over pretty much all other existing modes:
>
> FWIW, I don't, because we're not dealing with a clean slate.
>
> In the IETF context, whether or not OCB is a bit better
> then currently deployed modes is not an interesting
> question.
>
> One interesting question might be: is OCB so much better
> that it could we displace uses of some existing mode with
> OCB. That seems unlikely to me for the widely used modes.
>
> Another interesting question might be: is OCB so much
> better that we want to deploy it alongside current modes.
> I don't see the overall benefit of that myself.
>
> So even though I'm happy to accept that OCB has better
> properties than e.g. GCM, I don't think it's so much
> better that RFCs for it are that useful.
>
> That said, if the RFC for such a thing said "this is nice
> for brand new stuff (although library support will be less
> comprehensive) but is not worth the costs associated
> with adding it to existing protocols" then I'd be less
> against such RFCs being produced. Understandably enough,
> that kind of statement doesn't get added to such RFCs;-)
>
> S.
>
> PS: In case the ISE is still listening, the above is a
> reason why I think having CFRG produce this kind of RFC
> (instead of routing 'em via the ISE) would be a better
> plan. CFRG could (I think) likely reach better informed
> judgements (in the open) as to whether or not some crypto
> technique is really worth documenting in an RFC.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>