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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg