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

[Ben Campbell <[e-mail]>]

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

[…]