Re: [Last-Call] Last Call: Moving RFC 4491 to Historic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Replying to this one specifically because John rubbed the magic lamp and
muttered my name...

> If we have already waited two years since use was
> "forbidden" and eight years since the relevant GOST specs were
> deprecated, would harm be done by delaying this until those
> issues can be sorted out (see below)?

I see no harm in waiting given the time frame.

> (1) I can guess, but who is doing the "forbidding" and is that
> any more binding on potential users of international voluntary
> standards or binding national standards outside that country
> than a SDO requirement that something should be used?  Should
> that be reflected in the tracker notice?

Weeeell, who can forbid anything on the Internet?
So, perhaps, more context to this forbidding would have been better. It is
probably (but don't quote me) that the use of these algorithms in Russian
government infrastructure and associated public services in Russia is
forbidden.

> (2) Did the revised GOST standards and/or the deprecation or
> "forbidding" actions provide technical explanations of why
> continuing use of the specifications is a bad idea?  If so,
> should the documents containing that explanation be referenced
> in the tracker notice and/or the ISE and authors of the new
> document strongly encouraged (especially since IESG review seems
> to be in progress -- see below) to include explanations and/or
> references?  Adrian, consider yourself encouraged :-(

There are two very separate things here.
1. Should the Status Change notice (generated by the IESG) include more
explanation or references? I think we are all free to encourage the IESG
to collect this information and include it.
2. Should draft-deremin-rfc4491-bis make reference to the "deprecation" of
the old algorithms? I think not - indeed, the original version of the
draft did make that reference at a high level (hence the draft name), but
since that:
a. resulted in an Independent Submission changing the status of an IETF
Stream document
b. was not actually relevant to the purpose of *this* document
...I instructed the authors to remove all mention of RFC 4491.

Sorry if the file name served to confuse anyone, but this isn't the first
time a file name has not kept up with the content of a draft.

For reference, *this* draft describes how to use the GOST R 34.10-2012 and
GOST R 34.11-2012 algorithms with the Internet X.509 Public Key
Infrastructure. So it is similar to RFC 4491, but for a different set of
algorithms.

> (3) If there is a document "being progressed in the Independent
> Submission Stream" (I assume, after a quick search,
> draft-deremin-rfc4491-bis-10, now in IESG review), is there some
> reason to not delay the action of this Last Call and
> corresponding explanation until that document is approved and
> assigned an RFC number (at least a pre-publication one) so that
> RFC or other document can be cited?  Since the I-D has not yet
> been approved for publication, there is, at least in principle,
> a possibility that it will never be published.  In that case,
> part of the explanation would become retroactively incorrect.

Yes, it is *possible* that it will never be published, but I would be
"disappointed".
Is there harm to the delay? No. The move to Historic is needed, but as you
say, it has already been two years.
Is there value to the delay? I don't think so. This new document and RFC
4491 are independent. They have similar purposes, but apply to different
algorithms.
Will someone pick up 4491 by mistake? I hugely doubt it. An implementer
will be looking out for how to implement a specific GOST algorithm with
the X.509 PKI and so they will look for the RFC that mentions that
algorithm. They will be responding to the environment for which they are
implementing (which is the environment that has rendered 4491 historic).

> ...Perhaps more important substantively and longer-term:
>
> (4) RFC 4491 is identified as updating RFC 3279.  Given Brian's
> question and multiple controversies on other lists (most
> recently ART) that I would characterize as about the risk that
> moving documents to Historic may leave other specifications that
> they update or reference in confusing and/or silly states, has
> that been considered?  I believe it is not the case here and
> that 4491 just added to the list of IETF-recognized algorithms
> that should be included in the 3279 list.  However, if that is
> the case, should the explanation of this change explicitly
> identify that?   The collection of updates that add some
> algorithms, deprecate or modify others, and move still others to
> Historic without explicit metadata links from 3279 (see, e.g.,
> RFCs 6149 and 6151) and the similar collections for RFC 3121
> (itself referenced from 3279) appear to be creating a
> hard-to-follow, spaghetti-threaded collection for 3279 that is
> strongly reminiscent of the motivation for the NEWTRK ISD
> proposal.   Assuming the IESG is not inclined to reopen that
> issue and proposal, is it time to replace 3279 with a version
> that sorts the issues out and perhaps puts more reliance on a
> registry of applicable specifications and/or an Applicability
> Statement (see below)?  Such an RFC3279bis could handle the
> assorted new, Obsolete and Historic specs in a way that would
> much more clearly define their status and role (including the
> "IETF Endorsement" issue discussed below).

You know how no-one knows what "Updates" means? It appears (to me) that
RFC 4491 updated RFC 3279 only in the sense that it supplemented the list
of algorithms. I don't think I would have considered that as an Update
when I was on the IESG 😊

However, making a document Historic when it had previously made an
"Update", surely just means that the "Update" is no more.

The "IETF endorsement" is a whole different kettle of ballgames. But see
below...

> (5)  When we publish references to, translations, or
> explanations of documents from other standards bodies in the RFC
> Series, I believe we have precedent for both publication as
> Standards Track, IETF Stream Informational, and Independent
> Stream Informational.

Maybe precedent is not always a good guide to what we should next time
around?

> Especially when there are interactions
> with Standards Track specifications, the decisions as to how to
> treat them are normally made after due consideration by the
> community.  Such a decision was presumably made when RFC 4491
> was put on the standards track and as updating 3279.

2006 was a long time ago. The IESG evaluation record for RFC 4491 shows no
Comments. The draft came through the PKIX working group. The IESG writeup
shows...
  Initially
  this document was expected to be an Informational RFC, but when the
  PKIX WG Chair suggested that this document become a Standards Track
  RFC, there was no objection.

Make of that what you like.

>  The
> abstract of draft-deremin-rfc4491-bis-10, includes
>
>	"This document does not imply IETF endorsement of the
>	cryptographic algorithms used in this document".
>
> While 4491 is a Proposed Standard, implying precisely that
> endorsement of earlier versions of GOST R 34.10 and 34.11.   If
> the combination of this action and that document is intended to
> actually deprecate recognition of these GOST specifications as
> part of the RFC 3279 package, that feels like a Big Deal on the
> IETF's part, not a simple move of an obviously obsolete
> specification to Historic.  Such a Big Deal clearly (at least to
> me) needs documentation, especially if "we" have concluded that
> the GOST specs are not technologically appropriate and should
> not be recommended.  Of source, RFC 2026 strongly implies that
> attaching "Not Recommended" to a specification requires an
> Applicability Statement.  Those need IETF Last Call and RFC
> publication.  Such an A/S would be a reasonable alternative to
> replacing 3279 and would perhaps be an even easier way to
> explain the status of the assorted documents that have attached
> themselves to it as "updates".

I can't be definitive, but I suspect that the processing of 4491 did not
consider the implication that the IETF was endorsing the specific GOST
algorithms. Of course, we have moved forward a lot with crypto since those
days and are much more careful about what the IETF endorses.

> Assuming the IESG does not just pause this document waiting for

"this document" is the Status Change document? Right?

> either 3279 or that A/S for it and related documents, would it
> not be more appropriate for the IESG to move 4491 from Standards
> Track to Informational (explaining the reasons for downgrading
> the lineage in the process) and then use draft-deremin-... to
> explain how the GOST specs are used for those who choose to use
> them despite not being part of the 3279 collection any more?  Of
> course, if draft-deremin-rfc4491-bis were published in the IETF
> stream, those steps, including further updating 3729 if
> appropriate, could be handed cleanly with a single Last Call (or
> almost as cleanly by the ISE being given permission to obsolete
> an IETF stream Informational document and then asking for an
> advisory call on its approval).

I think it is highly doubtful that the IETF would endorse the publication
of draft-deremin-rfc4491-bis in the IETF Stream. I would be happy to be
proved wrong, but I suspect that access to the research on the algorithms
concerned is tricky, and the Crypto Review Team would say "unproven".

While it might be nice to request that the authors of
draft-deremin-rfc4491-bis include other material and so provide a document
to somehow downgrade RFC 4491, that is not the purpose of his document and
so you might have to exert some persuasion.

In fact, I think that *if* the Status Change document is not considered
adequate for this purpose, what is needed is a separate document, run
through the IETF (possibly AD sponsored) that describes the history and
technical reasons to deprecate RFC 4491. It is possibly that the authors
of the present draft would step forward to do that. Or not.

In case anyone is lacking access to a search engine,
https://www.russiangost.com/p-65695-gost-r-3410-94.aspx is a useful
indication that GOST R 34.10-94 is "not effective - superseded" (I presume
that means "not in effect", but possibly there is some method in the
choice of language!). I presume similar statements can be found for the
other algorithms. There are plentiful search results giving explanations
of the changes in the algorithms and hinting at reasons.

Btw. No one has mentioned RFC 4490. I wonder about that.

Coda:
I think that only part of this thread is relevant to the ISE and the
Independent Submissions Stream. That part is the progression of
draft-deremin-rfc4491-bis, and I am unchanged in my opinion that that
document is ready to be published as an Informational RFC in the
Independent Stream. The IESG conflict review
(https://datatracker.ietf.org/doc/conflict-review-deremin-rfc4491-bis/)
completed its ballot yesterday (Thursday 7th January) and shows "The IESG
has concluded that this work is related to IETF work done in WG LAMPS, but
this relationship does not prevent publishing." The ballot shows no
objections, but a few useful Comments that will be addressed in a new
revision of the draft before it is passed to the RPC. If the IESG would
like to put a hold on this document, they should speak up "SOON" [1]

Cheers,
Adrian

[1] https://www.ietf.org/archive/id/draft-farrel-soon-07.txt
-- 
Adrian Farrel (ISE),
rfc-ise@xxxxxxxxxxxxxx


> --On Friday, January 7, 2022 09:08 -0800 The IESG
> <iesg-secretary@xxxxxxxx> wrote:
>
>>
>> The IESG has received a request from an individual participant
>> to make the following status changes:
>>
>> - RFC4491 from Proposed Standard to Historic
>>     (Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R
>> 34.11-94     Algorithms with the Internet X.509 Public Key
>> Infrastructure Certificate     and CRL Profile)
>>
>> The supporting document for this request can be found here:
>>
>> https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t
>> o-historic/
>>
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send
>> substantive comments to the last-call@xxxxxxxx mailing lists
>> by 2022-02-04. Exceptionally, comments may be sent to
>> iesg@xxxxxxxx instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> The affected document can be obtained via
>> https://datatracker.ietf.org/doc/rfc4491/
>>
>> IESG discussion of this request can be tracked via
>> https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t
>> o-historic/ballot

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux