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

"Blumenthal, Uri - 0553 - MITLL" <> Sun, 10 March 2019 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDF931277CD; Sun, 10 Mar 2019 16:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Q40Lbx3A58j; Sun, 10 Mar 2019 16:38:33 -0700 (PDT)
Received: from (LLMX3.LL.MIT.EDU []) by (Postfix) with ESMTP id 7B171126C87; Sun, 10 Mar 2019 16:38:32 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id x2ANcUFr043370; Sun, 10 Mar 2019 19:38:30 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "StJohns, Michael" <>
CC: Stephen Farrell <>, CFRG <>, "RFC ISE (Adrian Farrel)" <>, secdir <>
Thread-Topic: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts
Thread-Index: AQHU15MRh5fmrRoU9kWbbFEvG0YyAKYFyJ4A
Date: Sun, 10 Mar 2019 23:38:29 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
Content-Type: multipart/signed; boundary="Apple-Mail-54D6C62B-D817-43FC-A107-6E41328022A4"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_20:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100182
Archived-At: <>
Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Mar 2019 23:38:37 -0000

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.


Sent from my iPhone

> On Mar 10, 2019, at 18:46, StJohns, Michael <> 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 <> 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 mailing list