Re: [saag] SSH & Ntruprime

[David Schinazi <[e-mail]>]

This is quite a long thread, so I apologize if I missed some of it.

While I don't personally oppose publishing RFCs to document existing
practice, registering a codepoint is absolutely not a good reason to
publish an RFC (unless of course the codepoint is in a registry that has an
IANA policy of RFC Required, IETF Review, or Standards Action - which isn't
the case any more for SSH Key Exchange Method Names [1]).

The registry that started this discussion (SSH Key Exchange Method Names)
is set up as Expert Review, so there's no requirement to have a
specification, and even if there were, that requirement is met by the
existence of an Internet-Draft. This is a technique that we've used
extensively in QUIC (for provisional registrations). I've personally
registered values with their reference set to a draft, or set to a wiki
page on GitHub, or with no reference at all. (Note that references to draft
need to include the draft number, because that then makes it as immutable
as an RFC.)

Taking a step back, the primary goal of an IANA registry is to avoid
collisions, and that can be easily accomplished without any public
specifications. I think it's good practice to document protocols and to
place the reference in the registry next to the code point, but it's by no
means a hard requirement. Additionally, the purpose of documenting
protocols at the IETF is not only interoperability, it's intellectual
property rights. Any Internet-Draft submitted to the datatracker is covered
by RFC 8179, meaning that anyone can check for IPR on the datatracker and
decide that they can implement this without having to worry too much about
patents (I'm not a lawyer, talk to your lawyer before you do this, etc.).

If there is IETF consensus to publish something as RFC, then by all means
do it. If there isn't, then don't. The registries don't come into it.

David (no hats)

[1] https://www.iana.org/assignments/ssh-parameters
[2] https://www.iana.org/assignments/quic

On Tue, Mar 26, 2024 at 12:39 PM Michael StJohns <[e-mail]>
wrote:

> On 3/26/2024 5:37 AM, Carsten Bormann wrote:
>
> Folks , Randy is right.
>
> If this discussion is intended to spark a rule change, please keep in mind
> that these rules weren’t made for the security area, but for the whole of
> IANA. Please don’t damage the parts you don’t know about.
>
> For clarification, the rules with respect to "Specification Required" were
> altered by 8447, for TLS and apply only to to the registries covered by
> 8447.  This rules change happened without broad community review, and
> indeed without much review within the security area.  The notes within 8447
> do not - to my mind - reflect a community consensus to change the status of
> Internet-Drafts globally, nor should RFC8447 be given "precedent" status
> with respect to future and pending documents.
>
> The rules for Specification Required have not changed and an Internet
> Draft is not a stable reference for the purpose of 8126 "Specification
> Required" section 4.6.  for anything but 8447 and it's unclear from the
> public record that the IESG of the time had sufficient information for
> informed consent of the RFC publication with those notes in it.  It's
> possible the private IESG archive will have more details than is present in
> the data tracker for RFC8447.
>
> So I'm arguing against a rules change because I think we're still at
> status quo with everything except the TLS registries touched by RFC8447.
>
> If there is an intent to make ID's stable references, the following things
> (IMHO) must be addressed:
>
> 1) The specification of a URL form that will be stable and a commitment by
> the LLC and tools teams to maintain an archive in that place in
> perpetuity.
>
> 2) The IANA agreeing that the archive is sufficiently stable that they
> don't need to copy documents into their part of the web tree as appears to
> be happening now with IDs.
>
> 3) A resolution of the whether the "stable reference" may point to the
> entire ID sequence (e.g. via the datatracker) or must it point to a
> specific stable document (e.g. a copy of "draft-stjohns-foo-02.txt") and
> this needs to be consistently applied.
>
> As of right now, there is at least one reference in the TLS registries to
> a draft -01 version, but which has been replaced by a draft -02 version in
> the datatracker.  It's unclear to me (and I would think a non-TLS
> participant or non-author) as to which reference the code point applies and
> its a manual step to research the datatracker link from the IANA registry
> entry.  I did not dig deeper here - it's possible the code point was an
> early assignment of a pending RFC, as opposed to RFC8447 assignment.  As
> part of this resolution, consideration might want to be made of:
>
>    - whether or not an "only an ID" reference will be identified
>    separately from an early code point assignment.
>    - whether or not the assignment of a code point to a "not ever an RFC
>    ID" locks the ID chain and prevents further submissions.
>
> 4) An update to RFC8126 section 4.7 to clarify that IDs are permitted, and
> an update to the ID boilerplate reflecting their new status.
>
> 5) (?) An update to the Trust Legal Provisions may be necessary. E.g.
> Additional ID boiler plate so that an author can restrict the referencing
> of an ID for the purposes of a code point assignment?  Similar to:
>
> This document may not be modified, and derivative works of it may not be
> created, and it may not be published except as an Internet-Draft.
>
> 6) The LLC and IANA agreeing to all of the above and providing funds if
> necessary to implement any necessary changes on the part of the tools team
> and the IANA and RFC editor.  For the RFC editor, citing an ID for the
> purpose of citing the document that owns a code point is different than our
> current ID cites, but may be necessary for some future documents.  The
> consequences should be explored and described with respect to a change of
> status for IDs.
>
> As I said, I don't necessarily disagree with what RFC8447 is trying to do,
> but I think it hand waves a bit too much and leaves a bit too much unclear
> for the future to clean up.
>
> Note that I do not consider that the above changes fall within the remit
> of either the RSAB or the RSWG, and definitely not within the remit of TLS.
>
> Later, Mike
>
>
> Sent from mobile, sorry for terse
>
> On 26. Mar 2024, at 04:20, Randy Presuhn
> <[e-mail]> <[e-mail]>
> wrote:
>
> Hi -
>
> On 2024-03-25 12:50 PM, S Moonesamy wrote:
>
> Hi Mike,
>
> At 11:49 AM 25-03-2024, Michael StJohns wrote:
>
> Context for the IETF list.  A set of IANA notes were included in RFC8447
> that allowed IDs to be considered as satisfying "Specification Required"
> for the purpose of issuing code points in IANA registries.  The IANA
> requires stable references for a Specification Required.  However, to quote
> from the ID boilerplate,  "It is inappropriate to use Internet-Drafts as
> reference material or to cite them other than as "work in progress."
>
>
> These two seem to be in conflict.
>
> The "Specification Required" policy is defined in "Guidelines for Writing
> an IANA Considerations Section in RFCs" (BCP 26) as a formal public
> specification.  The BCP also contains some information about the intent
> behind the policy.  I'll quote some text from the BCP as it may easier for
> the occassional reader:
>
>   "Publication of an RFC is an ideal means of achieving this
>
>    requirement, but Specification Required is intended to also
>
>    cover the case of a document published outside of the RFC path,
>
>    including informal documentation."
>
> There is also another policy which states "RFC Required" which is a bar
> higher in comparison with "Specification Required".
>
> The "IANA Registry Updates for TLS and DTLS" (RFC 8447) is on the
> Standards Track.  The RFC is about instructions for the designed experts
> and IANA.  Section 12, for example, states that "It is sufficient to have
> an Internet-Draft (that is posted and never published as an RFC) or a
> document from another standards body, industry consortium, university site,
> etc."
>
> There is a conflict between BCP 26 and RFC 8447.
>
> ...
>
> What is the conflict you see?  The text you cited seems to me to present
> no conflict.  A posted Internet-Draft certainly seems to fit within
> the realm of "a document published outside of the RFC path, including
> informal documentation."
>
> Randy
>
>
>