Subject: [Gen-art] Genart last call review of draft-ietf-curdle-ssh-ext-info-10

From: Matthew Miller <[email-masked]>
Date: Mon, 24 Jul 2017 14:02:39 -0700

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>.

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.

---

From: denis bider <[email-masked]>
Date: Tue, 25 Jul 2017 16:24:24 -0600

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 <
[email-masked]> wrote:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: "Matthew A. Miller" <[email-masked]>
Date: Wed, 26 Jul 2017 13:28:12 -0600

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:
> "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
> "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."
> 
> 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.
> 
> 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.
> 
> 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
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Reviewer: Matthew Miller
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/curdle>
> 
>

---

From: denis bider <[email-masked]>
Date: Wed, 26 Jul 2017 21:09:19 -0600

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."

---

From: denis bider <[email-masked]>
Date: Fri, 28 Jul 2017 00:52:57 -0600

OK, I have uploaded version -11 with language as follows:

"An extension MAY dictate, where it is specified, that in order to take
effect, both parties must include it in their EXT_INFO; or it MAY be
sufficient that only one party includes it; or other rules MAY be
specified. The relative order in which extensions appear in an EXT_INFO
message MUST be ignored by default; but an extension MAY specify that the
order matters for that extension, in a specific way."

This seems clearer to me than it was in -10. If you still see room for
improvement, let me know!

On Wed, Jul 26, 2017 at 9:09 PM, denis bider <[email-masked]>
wrote:

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

---

From: "Matthew A. Miller" <[email-masked]>
Date: Fri, 28 Jul 2017 10:05:04 -0600

Hello Denis,

I had other things I needed to attend to, and could not respond until
now.  I think this new text is much improved, thank you.

I find the guidance for an extension's specification to be more vague
than I like, but I'm maybe that's effectively addressed with the IANA
extension table's registration requirements.

Thanks again,

- m&m

Matthew A. Miller

On 17/07/28 00:52, denis bider wrote:
> message MUST be ignored by default; but an extension MAY specify that
> the order matters for that extension, in a specific way."
> 
> On Wed, Jul 26, 2017 at 9:09 PM, denis bider <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     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
>         <mailto:[email-masked]>
>         > <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>         >
>         >     Reviewer: Matthew Miller
>         <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>
>         <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>>.
>         >
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         >     <https://www.ietf.org/mailman/listinfo/curdle
>         <https://www.ietf.org/mailman/listinfo/curdle>>
>         >
>         >
> 
> 
>