Re: [CFRG] Proposed CFRG process for handling errata

Eric Rescorla <ekr@rtfm.com> Sun, 27 December 2020 22:29 UTC

Return-Path: <ekr@rtfm.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 774AD3A0CD2 for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 14:29:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 IEBGvFjrjV3I for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 14:28:58 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 6001D3A0CCC for <cfrg@irtf.org>; Sun, 27 Dec 2020 14:28:58 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id o13so20273363lfr.3 for <cfrg@irtf.org>; Sun, 27 Dec 2020 14:28:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ttSocF6eoo03E0uPjbzv+/pWWtzs248zF40DWPmsUw0=; b=K1RoCHHgSUbtHz/snGIoUSJ9KPZmA6asKYfVrjPBaIBDaD0Y6cCUfs7ehsKv08txp+ uk91JuB6EVb38LoSUDIXDiOmRi1JHStO+hnZiMlREdrr1nWchvB2NYmPhKtad/KDcU5j CN0lyv7T1RYSDodAAQkhZs0n0mCnK7VEwIKAnP39jzCNcSUQzboZqJK/UWU8bGsIWyKc br3tHTz+g7PxAP/krkIJCddLOEE6BDc0Y18lPD/mnT+RncKTEYU+5minvYr2DJqq86cH QdTv2wh3N1j1vi5AqXI0Jve+APzsnQl5hNYOYawWdTJ2jczH9XhiOhsfxe00My13M+ew mKFA==
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=ttSocF6eoo03E0uPjbzv+/pWWtzs248zF40DWPmsUw0=; b=pGNdvpxDH06ep2XaBNHO73pQuxNEdJ2BzgCNrQ30fLRLY3u2A4nf5mWxUxmXY0eHiD 9M9rLWG77PmfgGg/Nu935+yPjrih182T+ZPZBJp9YucKI/QqPNBiIiTxKyHUf2HNqXQK QfzNIvYSPbRTlQ3HlVMcic1uHlEwCA/AxJHTrqFC4PF7gQ+wtm3FM9xYjlCvwocoD6YS yH80a5Dyq99IfDRxBZ5Z+mv5nh++hLCLCcQUhXXHMZ2S4+oZ0/yD4O0DNg6Op6yQKfhX sTnfF4vvkQl00Ox9CN0us6dj6cCRD7U1EnXCE+P2h7CUq/6SdDutsIWg2xXlNOk6zmZ2 9BOA==
X-Gm-Message-State: AOAM533ogf6vLD4wSEDN9A9VtW0QSjd92FiV8lQ5xXta+7Z6yOyIm4gP RIZY1vGu+78kys6csU4T1vkmywELu4kGA6aJBKQOXm6esvFgag==
X-Google-Smtp-Source: ABdhPJymoHm+jtBU29I+O87hGQAzNX9mT5HYUf7KuJun8OEgv0jnio9FOQglkeeKNV0084wOUujnBfq9gvnTnqqcnio=
X-Received: by 2002:a2e:918f:: with SMTP id f15mr19827140ljg.82.1609108136753; Sun, 27 Dec 2020 14:28:56 -0800 (PST)
MIME-Version: 1.0
References: <40067f90-ec2c-2a36-f6df-8afa97189cd1@isode.com> <47855176-ce02-07b2-3f78-6f373c6f118d@isode.com> <a822af77-d732-73d8-c2e9-475b1fcbb6c2@nthpermutation.com> <EF008FEE-F053-4595-ADEA-CD2E416B2DEB@vigilsec.com> <C3EB8DBD-40B4-4800-8452-80BDA100CF62@akamai.com> <392b54bf-afb3-81d7-84f4-857b2342ff9e@nthpermutation.com> <E6F8F1D5-DEEE-4E11-B453-E1CDD239D2D7@akamai.com> <CABcZeBM62XZSWN1P7rw3jbHukGD+WD=t9ptgJDXVh22OsyYXUQ@mail.gmail.com> <uwes80.qm0rf7.31eoyz-qmf@mercury.scss.tcd.ie>
In-Reply-To: <uwes80.qm0rf7.31eoyz-qmf@mercury.scss.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 27 Dec 2020 14:28:20 -0800
Message-ID: <CABcZeBOVVt9RS8Em1f-g=8NR8QxsrLdCoSsHOtspP4DN90Ow2A@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Russ Housley <housley@vigilsec.com>, cfrg <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000e58e4105b779aeba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4_xCp9oB7boCrsPzctz_8bTldoo>
Subject: Re: [CFRG] Proposed CFRG process for handling errata
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, 27 Dec 2020 22:29:01 -0000

On Sun, Dec 27, 2020 at 2:21 PM <stephen.farrell@cs.tcd.ie> wrote:

> Hiya,
>
> On Sunday, 27 December 2020, Eric Rescorla wrote:
> > To be honest, I'm torn.
> >
> > IMO Mike is right that what CFRG is doing is making standards and that
> > that's traditionally the domain of the IETF. OTOH, as Rich, Stephen, and
> > Uri have pointed out, the current process seems to be working well, so
> I'd
> > prefer not to disrupt that. I do think we should acknowledge that these
> are
> > standards (we implement based on them, they're full of normative
> language)
> > and perhaps it's worth looking into the question of how to publish them
> on
> > the standards track. Just thinking out loud, what if the IESG could
> > cherry-pick to-be-published CFRG documents for ST publication
> [potentially
> > at the request of CFRG/IRTFC Chair], do a last call, and if there was
> > consensus, publish them as Proposed Standard RFCs [perhaps on the IETF
> > Stream?].
>
> Not sure how much better that'd be vs. the downref registry?
>

Well, to the extent to which we think that things being labelled as
Standards Track matters, then it seems suboptimal to have a bunch of
documents which are effectively standards (and in many cases are far more
widely deployed than many of our Standards) being Informational.  And if it
doesn't matter, than one might ask why we bother to publish our protocol
specifications as PS.

I recognize that in the past a number of cryptographic algorithms were
brought in as Informational, but those were largely cases like MD5 where we
were just creating a stable reference for something that was externally
developed. ISTM that that's not the case for much of the CFRG's current
work.

-Ekr


> S.
>
>
> >
> > -Ekr
> >
> >
> > On Sun, Dec 27, 2020 at 1:55 PM Salz, Rich <rsalz=
> > 40akamai.com@dmarc.ietf.org> wrote:
> >
> > > I am glad you said “all good points”
> > >
> > > I am worried about making any changes because what we have now is
> working
> > > very well.
> > > _______________________________________________
> > > CFRG mailing list
> > > CFRG@irtf.org
> > > https://www.irtf.org/mailman/listinfo/cfrg
> > >
> >