[CFRG] CFRG does standards and that is a general problem. Was Re: OCB does not have an OID specified, that is a general problem

Michael StJohns <msj@nthpermutation.com> Tue, 08 June 2021 16:37 UTC

Return-Path: <msj@nthpermutation.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 B171C3A3661 for <cfrg@ietfa.amsl.com>; Tue, 8 Jun 2021 09:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 6TGDxADKze5H for <cfrg@ietfa.amsl.com>; Tue, 8 Jun 2021 09:37:18 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 56D593A360D for <cfrg@irtf.org>; Tue, 8 Jun 2021 09:37:15 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id g12so11088431qvx.12 for <cfrg@irtf.org>; Tue, 08 Jun 2021 09:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ZdEed9JQcXcalhk3qbu35aaBJ+07BM1dxHTsE2b+Yh0=; b=cJSL2DocLZb2tuYXwyrVT80lWc6yzdpEtHksQDtalhstVun7F5a0KzIXGqOcVDhJCg MatusUWxRa/m/+0iJQXshq3m5aZnyVT/JcOkHS/qwh2lB4FwO7vPsyqDYRb1nH9y67yD mCdf2gFNBH78UzkVRtNDtsPLmoRdBu/iqXfIStTgEjN81ahrzfwUgIRrIP5TV6+gCebG CMEPS5hScUvvKYPlJmPFht2ran+gfr5005356wCsAqhg8kOf/7oSw69a62voMJWfCZR1 F/kfuen/T22US/ZJAP98BMGm4w4n1KIqgkOf9ksOZgBDGJnYJ2vA7EplK9nHew8n6pUY 77gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZdEed9JQcXcalhk3qbu35aaBJ+07BM1dxHTsE2b+Yh0=; b=XqvAonvZFRC81Nv4rcCljgLsTlddM2qDODhArpJ5TVaQDOSnLg58jjV6AD98kv97bY +UUGNQCrDG1k3TNHry77qJbfbeiEZqI4wy8wSg+0f2LhZkAt3elV9sdrZdK09fmWdb86 /mDE6yPH811ApIceNreH9u1NkeJos0pw6bQdy8ZVttKc3bHV69jy6ATSsYaRtDSs6YTV llmc0i/RDqUkYl2CHNPXKBfwSImfoIly1UXNkw28LH18USx/0fiVAIpKXU5aJ8meq0Xh UkfRiLQKq7n7nqkdIkaiY9UMnOed1xdFBv9izg4KymHznfzaA4aHCIQaI1comsTvAie7 F9Mg==
X-Gm-Message-State: AOAM532j9f0A6VgixbzammFYEarJiUhFbhOD48TGUzEvVqy65R+8gZDr ujlkMDUIY3T8DGCCM6vAfODGsMouDWe/oS+f
X-Google-Smtp-Source: ABdhPJy8lW+6QmOZFOJUgzuSTBPWcwuLhu/mp2l7olEEkewTB4ic08x3a4vuxDMAMklgJha6Z8aKPQ==
X-Received: by 2002:ad4:45a6:: with SMTP id y6mr637740qvu.54.1623170233110; Tue, 08 Jun 2021 09:37:13 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id p8sm6527280qkm.119.2021.06.08.09.37.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 09:37:12 -0700 (PDT)
To: cfrg@irtf.org, IAB <iab@iab.org>, The IESG <iesg@ietf.org>
References: <CAMm+Lwizfw6=T28gGOgeGZ=4CEHsQ5BoWcAt5mOWbyJHLVJmuQ@mail.gmail.com> <B73FB6B1-3EFC-4AEA-9A99-8C047F478944@akamai.com> <773badc5fdc04c41a5ceea7ad4fe29fe@cert.org>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <d1788788-6478-3a33-b08a-c0189dc9acd6@nthpermutation.com>
Date: Tue, 8 Jun 2021 12:37:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <773badc5fdc04c41a5ceea7ad4fe29fe@cert.org>
Content-Type: multipart/alternative; boundary="------------11B95364C3FE5550C074CB65"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/GafhFndIAsgeLNXuNZc9JAT09W8>
Subject: [CFRG] CFRG does standards and that is a general problem. Was Re: OCB does not have an OID specified, that is a general problem
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, 08 Jun 2021 16:37:29 -0000

On 6/7/2021 9:53 AM, Roman Danyliw wrote:
>
>   * I would like to propose that in future assignment of relevant OIDs
>     and JOSE identifiers be considered a requirement for similar work.
>     If a spec for a symmetric mode isn't sufficiently specified to
>     enable interoperable implementation in CMS and JOSE, it is not
>     sufficiently specified to be an RFC.
>
> That’s a reasonable thing to ask for, and something that could be 
> caught by SECDIR or AD review.
>
> [Roman] Agreed in the general case for the IETF stream.  For RFC7253, 
> this review would have been during IESG conflict review because that 
> document was IRTF stream (which doesn’t have an SECDIR review, AD 
> review or even an IESG ballot).
>
> Roman
>
This seems to be yet another reason why the CFRG should be a WG and not 
an RG.

I know this is not a popular opinion, but I think by keeping the CFRG in 
the IRTF, we're actually hurting the IRTF.   In the deep murky history 
of the IRTF, the organization was originally (post Kobe) meant to be a 
place for exploration of a lot of different points of view.  The concept 
of a RG "adopting a draft" was pretty much anathema - the idea was for 
lots of competing ideas to make it through the publication filters after 
some peer review and thence on to the broader community for 
consideration within the protocol development community.   It was not to 
come to a "consensus" on the one true way.  It should be possible to go 
into a RG with an idea that meets the general theme and is at least 
plausible, without having to "win" a race of competing proposals, and 
come out of it with an RFC in much less than 2 years - even as an 
individual contributor.  I'm not sure that's still possible.

At this point, the IRTF is looking more and more like a more closed 
version of the IETF with many procedures mostly indistinguishable from 
the IETF.  A number of RGs even have IANA actions for their documents 
and that suggests standards creation is bleeding into the IRTF in a way 
that will diminish the worth of the IRTF as a place for ideas rather 
than finished designs.

In the instant discussion, OID assignment should be done using IETF 
procedures.  And discussions on changes to IETF procedures are (or 
should be?) probably out of scope for an RG.


Later, Mike