Re: [saag] National cryptography standards and other aspects and the IETF

[Phillip Hallam-Baker <[e-mail]>]

We have a choice between two bad options:

1) Award RFC status to documents describing content that is unreviewed or
reviewed and considered harmful
2) Repurpose the Internet Drafts series.

So I propose a third option, create a new untitled series.

RFCs are in theory requests for comments but that isn't the brand. IDs are
ephemeral and can be updated. Which is problematic to say the least,
someone can do a bait and switch attack.

Not giving the series a name is to prevent or at least discourage treating
these as being endorsed by any organization.


This series would need a URN form obviously, if it is human readable, there
will have to be someone running some sort of registry. So the identifiers
could be

draft-hallambaker-mesh-architecture-22

Might be published as

DOC:hallambaker-mesh-architecture
or
UDF:MBUF-P7S2-WFEF-D3ML-OKCC-XYOT-6SLD

UDF is just an improvement on the earlier work on ni in RFC6920. The
difference being that we did not intend people to type in a ni any time.

Using UDFs doesn't require any action on IETF part except publishing the
UDF draft as an RFC and possibly providing a repository of documents
referenced in IANA repositories retrievable by fingerprint.

So the way I would do this is to have an option in the ID draft tool to fix
the draft as a document. This would mean that any updates to the draft
would have to use a new name and replace the Internet Drafts boilerplate
with wording saying 'this is not endorsed'. It would then calculate the
SHA-2-512 hash of the XML source and return that to the user.

This is completely functional but the identifiers are opaque. But maybe
that isn't a problem because RFC numbers are opaque and I can't even
remember the numbers of the ones I wrote myself. We commonly abbreviate
patent numbers in legal cases without issue, UDFs can also be abbreviated,
but you have to specify the prefix, not the suffix, so UDF:MBUF-P7S2. This
is because the scheme is designed to allow the fingerprint to be given at
any level of precision according to need.


The DOC series is a more user-friendly solution as the document names are
at least comprehensible. But it would require quite a bit of support and
there is infinite scope for bike shedding.


I even have my own bikeshed color scheme, the callsign document identifier:

cd:phb.1:mesh-architecture

The global uniqueness of this identifier is attested through a
first-come-first-served append only log. phb.1 being the first registration
of the callsign phb. [phb.0 is the current holder allowing for transfers].

I am not proposing callsigns as a solution here, only raising it to
illustrate the scope of the colour scheme selection on offer.



On Fri, Aug 25, 2023 at 1:19 PM Adrian Farrel <[e-mail]> wrote:

> Beyond the scope of SAAG, of course, but I think you are arguing to change
> the I-D boilerplate so it no longer says…
>
>
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>
>    and may be updated, replaced, or obsoleted by other documents at any
>
>    time.  It is inappropriate to use Internet-Drafts as reference
>
>    material or to cite them other than as "work in progress."
>
>
>
> Adrian
>
>
>
> *From:* saag <[e-mail]> *On Behalf Of *Eric Rescorla
> *Sent:* 25 August 2023 18:03
> *To:* Russ Housley <[e-mail]>
> *Cc:* Independent Submissions Editor (Eliot Lear) <[e-mail]>;
> IETF SAAG <[e-mail]>
> *Subject:* Re: [saag] National cryptography standards and other aspects
> and the IETF
>
>
>
>
>
>
>
> On Fri, Aug 25, 2023 at 9:53 AM Russ Housley <[e-mail]> wrote:
>
>
>
>
>
> On Aug 25, 2023, at 12:16 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
>
>
>
>
> On Fri, Aug 25, 2023 at 8:57 AM Independent Submissions Editor (Eliot
> Lear) <[e-mail]> wrote:
>
> Hello all,
>
> I just wanted to follow up on Roman's message with an informational note.
>
> Use of national cryptographic suites in the IETF protocols have, as of
> late, been published as independent submissions to the RFC series.  See
> for example RFCs 8891, 9189, 9215, 9227, 9337, 9367, and 9385 for GOST.
>    There is at least one more such document in the ISE current queue,
> draft-culling-dnsop-sm2-alg.  The ISE also published CNSA 1.0  that
> contains cryptographic profiling of IETF protocols.  These profiles were
> published as RFCs 8603, 8756, 9151, 9206, and 9212.  I note that CNSA
> 2.0 was  announced in 2022 to address PQC.
>
> Neither the ISE, the IETF, nor the IRTF can impose our views on
> governments in terms of how they decide what cryptography to use or
> require in implementations.  The purpose of publishing these documents
> is, therefore, not to modify the cryptographic algorithms, but to
> encourage interoperability of implementations where these algorithms
> might be required.
>
>
>
> This is obviously a question for the ISE and the broader community rather
>
> than just the IETF, but FWIW I think this practice is somewhere between
>
> useless and harmful.
>
>
>
> As a practical matter, an I-D is entirely sufficient for documenting these
>
> algorithms. IDs are not "archival" in the RFC sense, but they are archived
>
> indefinitely. In many protocols, IDs can be used to register code points
>
> already, but to the extent to which protocols allow registration with just
>
> an ISE RFC, then they should be adjusted to allow IDs.
>
>
>
> I think this is harmful for two reasons:
>
> First, it consumes precious IETF and IRTF review time, which is a cost.
>
> Second, having these documents as RFCs creates the usual confusion
>
> about the status of the suites, which creates pressure to implement
>
> them, which is generally undesirable.
>
>
>
> For these reasons, I would encourage you to reconsider this practice.
>
> -Ekr
>
>
> That having been stated, it would be bad to publish documents that use
> known broken algorithms or algorithms that are so weak as to provide
> meaningless security or worse, the illusion of security.
>
> To that end, the ISE makes use of the crypto-panel run by the CSRG
> chairs for reviews. Unsolicited reviews are always welcome. You can find
> guidelines at https://www.rfc-editor.org/materials/reviewer.guide.txt.
> Those offering reviews will receive a very large heartfelt thank you,
> certainly from me, and almost as certainly from the authors.  Your
> reviews can and will improve the overall quality of the RFC series.
>
> I also try to ensure that documentation of the algorithm is freely
> available in English, and that there is at least one open source
> implementation of whatever specification is being propounded.
>
> The astute will note that there are some scaling risks associated with
> the current approach.  I think that is a long term matter that requires
> a consideration by our community and elsewhere.
>
> Eliot
> (ISE)
>
>
>
> I mostly disagree with Ekr.  I think that interoperability is very
> valuable, and I think it is important to know what algorithms are being
> used to protect traffic on the Internet in various situations.  If the
> practices are not written down in a public place, then it is difficult to
> for anyone to determine what protections, if any, are offered.  Remember
> when some people were advocating DES with a 40-bit key?
>
>
>
> My point is that IDs *are* a public space and these documents need not be
> published as RFCs.
>
>
>
> -Ekr
>
>
>
>
>
> I do wish there was a more obvious way to mark the documents as "for the
> information of the Internet community".  We have many information RFCs that
> have various meanings.  These document carry a statement like:
>
>
>
>    The purpose of this document is to make the specifications of the
>
>    cryptographic algorithms defined as a <Country> national standard
>
>    <identifier> available to the Internet community.
>
>
>
> One needs to open the document to see that statement.
>
>
>
>
>
>
>
> Russ
>
>
>
>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>