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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Sun, 10 March 2019 23:38 UTC

Return-Path: <prvs=8972f93211=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF931277CD; Sun, 10 Mar 2019 16:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q40Lbx3A58j; Sun, 10 Mar 2019 16:38:33 -0700 (PDT)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7B171126C87; Sun, 10 Mar 2019 16:38:32 -0700 (PDT)
Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x2ANcUFr043370; Sun, 10 Mar 2019 19:38:30 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "StJohns, Michael" <msj@nthpermutation.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
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: <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu>
References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <alpine.LRH.2.21.1903081227200.30421@bofh.nohats.ca> <CAHOTMVLtjVxZNy3bFRn09xH+cOw+tPi2CL3BkaQuJEqxAzGOJg@mail.gmail.com> <edca701b-21f3-c80c-d754-fc333f1e2e04@cs.tcd.ie> <20190310182935.GE8182@kduck.mit.edu> <B876B124-7EDE-4E20-A878-3AAD3FA074BC@krovetz.net> <20190310191026.GF8182@kduck.mit.edu> <CAHOTMVJcosEgYV9caWapgyzQfh-g4k5DQry5n42bEfrkJvmdWQ@mail.gmail.com> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <CANeU+ZCmiTKfE1_YgjM6GX9ZCw_35mZoT8M-6VL72UhbenT2og@mail.gmail.com>
In-Reply-To: <CANeU+ZCmiTKfE1_YgjM6GX9ZCw_35mZoT8M-6VL72UhbenT2og@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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: <https://mailarchive.ietf.org/arch/msg/cfrg/ty9cD2ZlRDfU7W3XjW0npjMNwBc>
Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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.

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