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

Richard Barnes <rlb@ipv.sx> Tue, 12 March 2019 18:57 UTC

Return-Path: <rlb@ipv.sx>
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 A2C151312F5 for <cfrg@ietfa.amsl.com>; Tue, 12 Mar 2019 11:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 hd1eL-3QXSLf for <cfrg@ietfa.amsl.com>; Tue, 12 Mar 2019 11:57:07 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A461312F0 for <cfrg@irtf.org>; Tue, 12 Mar 2019 11:57:07 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id a15so2876798oid.5 for <cfrg@irtf.org>; Tue, 12 Mar 2019 11:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sFmBZEM/zuqQP2E1gfp5ze5nbOG0R95fZceBCRQ5ipo=; b=p+amasmqmBLCBj/U8/4idsxuvfpj/gO7UtM/czOucHfRX78AURkxQnotby6Tdwmiw9 RW9g3JYjQmk0DEhNE86AVqPp5A1TY+RmAUDaxdnOE+w5x3lfhqR3O74yhWLqSTEd7G9w 0XPajoR58Qm1ETyZ3MHHnq76HkdOWJsLkz2iXGBSpI6jtf9hiAFwxvVaoJ/Low7BuUc4 JnWpstcvUCPUhJUTYtGp/paxRZkSzpUJ1NrJ7Z7Kcdgh8fdC1odLjY/KqrdAY9VWU3+o +OAwE6JklW7zOpHfsr88QAZ74VBKhLvcMcVr9NgZe3xs/tr85xsBu5KFO/Cahi2uVXsb 851w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sFmBZEM/zuqQP2E1gfp5ze5nbOG0R95fZceBCRQ5ipo=; b=TZaxajwKoyg2E9KhVr+EDi3knwAac+xbxZjWZ7qRosIOWitysj5jaL7vbLmfaG4MHP Y3wbXeAh77+TqndOQQ1ZImeyh0zSNOMObfaGToYNDHnQb0rz6CZUAE2Vhdwv1ftOHEJU nErWlfqpTa9I7Aar0HXLwaovfudaklx8au5oPSTeuos8gxMaaTm9vLgGR73c2tOQ4Jfy OGLa3cGv+BH2XwXRaoIi9hAd4eOicLNtK53vRrF4fZqjwfEgdA2PP2mSP29aZ9aQEKFN eFVCvTJr6aFzi+5pv1JVPMUbC8eTaDr6I/+Bz+O9LyiHzC6rYoIZjk2O5tldPvtV7o86 DyUQ==
X-Gm-Message-State: APjAAAWcL8kdeWhZHjgTe9NNoD3GyurqXvseeGqvK2RQvV5fN4G4ZNx2 bLEp2HkATuzM9DyNJP048Lb4EMNGPfcUkkHARA7YIv/Q
X-Google-Smtp-Source: APXvYqzJVkJZbDu0D/LtWy68ps0iN3FyDYP2Qt+ljXPCRMvlVABQJjyeSFEgmQRoGPbcVtHxMYERPLSBEuj0PF2d7VQ=
X-Received: by 2002:aca:f5c2:: with SMTP id t185mr2463201oih.135.1552417026274; Tue, 12 Mar 2019 11:57:06 -0700 (PDT)
MIME-Version: 1.0
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> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com>
In-Reply-To: <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 12 Mar 2019 14:56:38 -0400
Message-ID: <CAL02cgSeCgAOOh3oMhJZqCGvT0F=JQ6n-bmgWYU=6hxkV+aOHQ@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "StJohns, Michael" <msj@nthpermutation.com>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006512ba0583ea41cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/W2D44ETYvkYOo7-j3cTuflEw8cU>
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: Tue, 12 Mar 2019 18:57:10 -0000

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>rg>, CFRG <cfrg@irtf.org>rg>, "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
>