Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)

[denis bider <[e-mail]>]

> One approach might be to say an extension MUST NOT add binary values,
> but implementations MUST NOT fail if one is present for an extension you
> don’t understand.

Unfortunately, prohibiting extensions from having binary extension-values
would have significant ramifications that would look very unsightly in the
SSH protocol.

For example, for something like the "delay-compression" extension that
needs to encode two name-lists, if extension-value cannot be binary, then
it would have to be Base64-encoded. This would be a very questionable
choice in a protocol that is otherwise binary and has no reason to
pessimize itself this way, other than that one particular implementation,
at one point in time, used the wrong function to decode a string. :)



On Wed, Sep 13, 2017 at 10:53 PM, Ben Campbell <[e-mail]> wrote:

>
> > On Sep 13, 2017, at 11:47 PM, denis bider <[e-mail]>
> wrote:
> >
> > > I do not see a response to my comment on the “*” note in section 2.4.
> > > Did that change as part of the rewrite of that section that you
> mention below?
> >
> > Aye, sorry for not mentioning that. Most of the text was kept, but it
> was slightly rearranged. The sentence containing the inappropriate MUST was
> replaced with:
> >
> > "The timing of the second opportunity is chosen for the following
> reasons.”
>
> That works for me, thanks!
>
> […]
>
> > > The issue is redundant normative language, where it becomes
> > > ambiguous which piece of text is authoritative.
> >
> > Aye - it does violate the one-definition rule.
> >
> > I have changed the first mention as follows:
> >
> > "Implementers' attention is called to Section 2.5., in particular the
> requirement to tolerate any sequence of bytes - including null bytes at any
> position - in an unknown extension's extension-value.”
> >
>
> Thanks!
>
>
> > I have previously contemplated whether to add explicit mention of the
> OpenSSH behavior up to 7.5. On the one hand, it is poor practice to
> reference individual implementations. But on the other hand, this is a
> widespread implementation that everyone will want to interoperate with. If
> we provide no guidance about how to handle this bug, it will throw
> implementers for a spin, and worse, the compatibility workarounds may not
> be ideal. (E.g. people may avoid sending binary extension-values to ANY
> version of OpenSSH, instead of just versions up to 7.5.)
> >
> > For this reason, I have provisionally added the following section under
> the "delay-compression" extension:
> >
> >
> > 3.2.3.  Compatibility Note: OpenSSH up to 7.5
> >
> >   This extension uses a binary extension-value encoding. OpenSSH clients
> >   up to and including version 7.5 advertise support to receive
> >   SSH_MSG_EXT_INFO, but disconnect on receipt of an extension-value
> >   containing null bytes. This is an error fixed in OpenSSH version 7.6.
> >
> >   Implementations that wish to interoperate with OpenSSH 7.5 and earlier
> >   are advised to check the remote party's SSH version string, and omit
> >   this extension if an affected version is detected. Affected versions
> >   do not implement this extension, so there is no harm in omitting it.
> >   The extension SHOULD NOT be omitted if the detected OpenSSH version is
> >   7.6 or higher. This would make it harder for the OpenSSH project to
> >   implement this extension in a higher version, if they so choose.
> >
> >
> > This might be unusual, but since the bug exists in current versions, it
> will stay relevant for 5+ years. I think it may be worthwhile to ensure
> everyone's workarounds are consistent.
> >
> > The alternative would be to change the spec to disallow binary
> extension-values, but I think this is long-term inferior (especially since
> OpenSSH has committed to fixing the bug).
>
> I don’t have a strong opinion here. One approach might be to say an
> extension MUST NOT add binary values, but implementations MUST NOT fail if
> one is present for an extension you don’t understand. In any case, I will
> leave that to you and Ekr to decide.
>
> […]
>