Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10

Hello Matthew,

I'm not sure if I know how to address this better than with the language so
far proposed.

Perhaps one choice would be to simply remove this paragraph. However, the
reason it was added was because an earlier reviewer (I'm not sure of the
details at this time) raised the question about whether extension
negotiation works like it does for algorithm lists, such as in e.g.
SSH_MSG_KEXINIT. In that case, multiple algorithms are enumerated by both
sides, and only one is chosen that (1) is enumerated by both sides, and (2)
is the first of those to be enumerated by the client. The main purpose of
this paragraph has been to clarify that extension negotiation does not work
that way in EXT_INFO.

What language would you propose? Is there some simple language that would
do? How about this?

"An extension may dictate, where it is specified, that in order to take
effect, both parties must include it in its EXT_INFO; or it may be
sufficient that only one party does; or more complex rules may be
specified."

On Wed, Jul 26, 2017 at 1:28 PM, Matthew A. Miller <
linuxwolf+ietf@outer-planes.net> wrote:

> Thanks very much for the response, Denis.
>
> I think I understand the intent here, but I'm not sure this new text is
> enough to mitigate some future conflict.  I'm also concerned that it
> completely ignores the one-party extensions (e.g., an extension included
> in the EXT_INFO by only the client or the server, but not both), and
> what the impact is holistically.  Looking at the one-party extensions
> defined herein, I can't see how their order matters; but does that mean
> the order will never matter?
>
> In writing this reply, I wondered if it's better for the order to always
> be irrelevant; an implementation might be allowed to hint its preferred
> order in the EXT_INFO, but implementations are still free to do whatever
> makes sense to them within the bounds of the relevant extension
> definitions.  If an extension ought to take precedence over another,
> make it clear in its specification that it SHOULD (or MUST) be dealt
> with before (or after) others.
>
> Does that make sense?
>
>
> - m&m
>
> Matthew A. Miller
>
> On 17/07/25 16:24, denis bider wrote:
> > Good catch. I believe this refers to the following paragraph:
> >
> > "If an extension requires both the client and the server to include it
> > in order for the extension to take effect, the relative position of the
> > extension-name in each EXT_INFO message is irrelevant."
> >
> > I have drafted the following new wording:
> >
> > "Unless a particular extension's specification indicates differently;
> > then, if an extension requires both the client and the server to include
> > it in order for the extension to take effect; implementers MUST use a
> > default assumption that the relative position of the extension-name in
> > each EXT_INFO message is irrelevant with respect to whether the
> > extension takes effect."
> >
> > The purpose of this wording is to:
> >
> > - Provide a sensible default, which is that in the absence of specific
> > knowledge, order of extension names does not matter.
> >
> > - Allow for deviations in special cases where there is specific
> knowledge.
> >
> > For example, extension "foo-linux" could be specified, but after some
> > years of use, it's observed that it works well for its main purpose, but
> > is not ideal for a server on Windows. Therefore, extension "foo-windows"
> > is specified, which works well when the server is Windows, but not as
> > well when it's Linux.
> >
> > In this case, an implementation that supports "foo-linux" only would be
> > ignorant of anything else, and would use the default rule (order of
> > extension names does not matter). However, an implementation that
> > supports "foo-windows" could implement only that, or both "foo-linux"
> > and "foo-windows". The specification for "foo-windows" could indicate
> > that when both are supported, the first one listed by the server (or in
> > other cases, by the client) is used.
> >
> > Allowing for such an extension-defined special case would allow a Linux
> > server to advertise extensions [... "foo-linux", ..., "foo-windows",
> > ...], preferring "foo-linux", but supporting the less appropriate
> > "foo-windows" mechanism as well. Whereas, a Windows server could
> > advertise [... "foo-windows", ..., "foo-linux", ...], preferring
> > "foo-windows", but supporting the less appropriate "foo-linux" mechanism
> > as well.
> >
> > Does this work?
> >
> > If there are no objections, I'll upload a -11 draft version with this
> > new wording.
> >
> >
> >
> > On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller
> > <linuxwolf+ietf@outer-planes.net
> > <mailto:linuxwolf+ietf@outer-planes.net>> wrote:
> >
> >     Reviewer: Matthew Miller
> >     Review result: Ready with Issues
> >
> >     I am the assigned Gen-ART reviewer for this draft. The General Area
> >     Review Team (Gen-ART) reviews all IETF documents being processed
> >     by the IESG for the IETF Chair.  Please treat these comments just
> >     like any other last call comments.
> >
> >     For more information, please see the FAQ at
> >
> >     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
> >     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> >
> >     Document: draft-ietf-curdle-ssh-ext-info-10
> >     Reviewer: Matthew Miller
> >     Review Date: 2017-07-24
> >     IETF LC End Date: 2017-07-30
> >     IESG Telechat date: N/A
> >
> >     Summary:
> >
> >     This document is ready with an issue.
> >
> >     I found this document very coherent and easy to follow.
> >
> >     Major issues:
> >
> >     Minor issues:
> >
> >     My only issue borders on nit, but sided with nit as I can see it
> >     potentially causing confusion for an implementer in the future.
> >
> >     Section 2.5. "Interpretation of Extension Names and Values"
> explicitly
> >     states in the second paragraph a condition where the relative order
> of
> >     extension-names in an EXT_INFO message is irrelevant.  However, the
> rest
> >     of the section seems to imply to me that relative order is not
> >     important;
> >     so to explicitly call out a scenario seems to imply that relative
> order
> >     *is* relevant/important, sometimes.  If relative order is expected
> to be
> >     important most of the time, I think it helpful to explicitly state
> that
> >     and give a rationale for it.
> >
> >     Nits/editorial comments:
> >
> >     * RFC 5226 is referenced by this document, but is obsoleted by RFC
> 8126.
> >
> >
> >     _______________________________________________
> >     Curdle mailing list
> >     Curdle@ietf.org <mailto:Curdle@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/curdle
> >     <https://www.ietf.org/mailman/listinfo/curdle>
> >
> >
>
>