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

mcgrew <mcgrew@cisco.com> Tue, 19 March 2019 13:23 UTC

Return-Path: <mcgrew@cisco.com>
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 337D8127978 for <cfrg@ietfa.amsl.com>; Tue, 19 Mar 2019 06:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Dpcs81BW2XgR for <cfrg@ietfa.amsl.com>; Tue, 19 Mar 2019 06:23:24 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD20131272 for <cfrg@irtf.org>; Tue, 19 Mar 2019 06:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6406; q=dns/txt; s=iport; t=1553001803; x=1554211403; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fUpzD/o58rbIjGgrgHFMfaqdFmAibQ1/t6ZpSlpuW6g=; b=Kj/sqIMDWUBtuMsAiw5luQgP3ZIMXBKjl/mfOOrbiQz8DAyuPaE7Efn0 QLuJUi8JZv+kmOrPfx2LvrDierG3LfF6KrM1lIp8sgMriiozpLGAfOr57 m9dBz+wzbRwfc6N3rMCQ3HT/ikhp/Rf7L2bPKO/Ag1hMocjcze5D7bGAp k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAADf7JBc/4gNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgWYqaIEDJwqEY5JkgWglmi0LAQEYC4R?= =?us-ascii?q?JAoRrIjcGDQEBAwEBCQEDAm0cDIVKAQEBAQIBAQElEzEDCwULCwkPHgULJzA?= =?us-ascii?q?GDgWCV0sBgW0ID6pHM4REQYU0BYEvAYlsgUQXgT9AgREnDBOCHi6DHgEBAwG?= =?us-ascii?q?BPQEBHoM7giYDigozH5ktYAmDQIQdi08ZgXyFcohIgyiDTI07ihiCcAIRFYF?= =?us-ascii?q?dIoFWcBU7KgGCDQEzPoFYFxNtAQGHXYVbIwEBMYd3gR8BgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208";a="537244422"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 13:23:17 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JDNGpj002584 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 13:23:16 GMT
Received: from rtp-mcgrew-nitro3.cisco.com (10.117.145.148) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 08:23:15 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: mcgrew <mcgrew@cisco.com>
In-Reply-To: <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com>
Date: Tue, 19 Mar 2019 09:23:03 -0400
CC: Richard Barnes <rlb@ipv.sx>, secdir <secdir@ietf.org>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <AE9AC4D7-6863-4AC5-BDE5-6B507AC9ADE6@cisco.com>
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> <CAL02cgSeCgAOOh3oMhJZqCGvT0F=JQ6n-bmgWYU=6hxkV+aOHQ@mail.gmail.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <CAL02cgRVXn2U3SKhGh6biTZJKmHM6KrW6D_rVB2-ZTC5Oohh4w@mail.gmail.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Originating-IP: [10.117.145.148]
X-ClientProxiedBy: xch-rtp-012.cisco.com (64.101.220.152) To XCH-ALN-004.cisco.com (173.36.7.14)
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/L8ekB3D8y0pHTAvVjbyk6Pcmi1I>
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, 19 Mar 2019 13:23:28 -0000

Hi Mike,

Please see inline:

> On Mar 18, 2019, at 4:43 PM, Michael StJohns <msj@nthpermutation.com> wrote:
> 
> I don't understand - usually when I say "I'm fine with the status quo for now" people stop arguing with me.   Oh well.
> 
> And thanks David for making some points for me.  See below.
> 
> 
> On 3/18/2019 9:26 AM, mcgrew wrote:
>> Hi Mike,
>> 
>> Let me add few data points from a CFRG-historical perspective.  CFRG has been the first publisher of a number of specifications (for instance, XMSS, Poly1305, and HBS are in this category -  https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential review for some ISE-published crypto like UMAC (RFC 4418).
> 
> My point was that becoming a first publisher puts the CFRG into the position of being the standardizer.  XMSS, Poly1305 and HBS (not yet published) are all 2018 and 2019 documents.  EDDSA was 2017.  In fact the set of documents currently attributed to the CFRG only goes back to 2014 while the CFRG has been around a lot longer than that.  Something changed

The RG shifted from discussing and reviewing independent documents towards producing its own documents.  

> and now we're getting standards-like production out of the CFRG.  Note that I don't think its a bad thing per se, just that you need to be following different rules than those that are applicable to RGs.
> 
> For example, why does an informational document in the research stream need a registry?  (e.g. RFC8391)   That's about as obvious a standardization requirement as any I've seen in CFRG documents.

The registry and the interface and extensibility it provides is essential to making a crypto specification future-proof. That is clearly best practice in cryptography, and as such is totally appropriate for the output of an IRTF RG document.   Some independent documents that were reviewed by CFRG also had registries. 

David

> 
>>  For UMAC, it is worth noting that the ISE reviewers asked for changes around IPR language,
> 
> I don't think I even recall seeing anything that wants to use UMAC - I may have missed a protocol or two though.  In any event, the request was to REMOVE claims about IPR language from the document and direct the authors to make a normal IPR disclosure. Again - pretty consistent with what we do with standards and IETF stream documents.
> 
>> and CFRG reviewers made important improvements to the technical content as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail threads from fall 2005).  So the issues we are dealing with today are not really new.
> 
> But again, that's normal for any document that comes in through any stream - specifically - people review it and usually irrespective of association with a specific WG/RG/directorate, etc.  The fact that the document author, the ISE and the IESG reached out the the CFRG is pretty much an example of looking for the experts in a pile of experts.  I'm not sure why this wouldn't happen if the CFRG were chartered as a WG?
> 
> 
>> 
>> You have started a good, healthy discussion with the points that you have raised.  My thinking is that CFRG (including Kenny, Alexy, and the many contributors) is doing really good, really important work, and the IRTF and IETF should avoid changes that would disrupt it.
> 
> I don't want to change the people, I don't even want to change the work flow (much - except that moving it to a WG would actually remove the IRTF from the approval process for an RFC), I just want this to be appropriately categorized and managed as a WG and subject to the same rules as any other WG.   I think its gone well past the normal rules for an RG at this point.
> 
> Again - I've indicated my concerns and I'm happy the discussion is happening.  Unfortunately what I keep hearing is "we like it the way it is, now go and leave us alone" rather than "we're really a RG because we do things X, Y and Z so we really don't need to be a WG".  I'd really like to hear more commentary on that latter - especially how the CFRG in fact differs from the behavior of a WG.
> 
> Thanks - Mike
> 
> 
> 
>> 
>> Best,
>> 
>> David
>> 
>>> On Mar 15, 2019, at 2:52 PM, Michael StJohns <msj@nthpermutation.com> wrote:
>>> 
>>> On 3/13/2019 7:32 AM, Richard Barnes wrote:
>>>> Mike, are your concerns here primarily IPR related?  If that's so, then maybe that's the level at which we should address them, as opposed to flipping the bigger RG->WG switch.
>>>> 
>>> Hi Richard -
>>> 
>>> Like I said, I'm not going to push this at this time.  But I think its more than just IPR - avoiding technology because of IPR is more a symptom (and in fact is IETF guidance rather than IRTF policy).
>>> 
>>> The CFRG has a unique position in that - unlike ANY other RG as far as I can tell - it's looked at as an immediate feeder for technology for the IETF.  If it were agnostically evaluating the crypto properties of any offered technology, I'd say we're good and I'd move on.  But, with the publication of Curve25519 and its related ... standards ..., the CFRG has moved from evaluation and re-publication of cryptographic standards developed and produced elsewhere into being the first publisher of what could only be characterized as standards, even if published as an Informational RFC in the IRTF stream.
>>> 
>>> Ultimately, I think it comes down to fairness and transparency. As an RG, the publications of the RG are not subject to the standards appeals process.  In an WG, the decision not to work on an IPR encumbered technology (or others such as national cryptography) MAY be appealed and overturned (or might not) or sponsored by an AD if there's no applicable or agreeable WG. There's a process for showing such decisions were made transparently, and with a broader audience than just the CFRG having a say.
>>> 
>>> 
>>> Later, Mike
>>> 
>>> Ps - hmm... Note that the CFRG charter only mentions the IETF and not the IRTF....
>>> 
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/cfrg
> 
>