Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

I think it's appropriate as an explicit clarification of the behavior the RFC intended, and which most implementations implement (but some don't).

I don't think It's too late because errant implementations can correct this, and in time new versions of these implementations will be used.

Don't think in 2-3 years time, think in 10 years time. Internet protocols tend to hang around for a while. SMTP has been around for 33 years...


Jeffrey Hutzelman <[email protected]> , 11/13/2015 3:12 PM:
On November 13, 2015 9:39:23 AM EST, denis bider <[email protected]> wrote: 
>Much agreed. 
> 
>If the IETF will accept an erratum with a clarification, here's a 
>proposed wording: 
> 
> 
>"Servers and clients may or may not be aware of a future extension to 
>this RFC that specifies a use for the KEXINIT reserved field. 
> 
>Servers and clients that are NOT aware of such an extension: 
>- MUST send the reserved field with the value zero (indicating 
>unawareness); 
>- MUST NOT act on any value of this field when received, whether zero 
>or non-zero; 
>- in key exchange, MUST properly hash the actual received value of this 
>field. 
> 
>This behavior is REQUIRED to allow use of this field in future protocol 
>extension." 
 
It certainly was a mistake not to specify this to begin with.  However, this represents a change to the protocol, not correction of a technical inaccuracy in the document.  Nor is it a change to reflect common, consistent actual practice which differs from the specified protocol.  So, I don't think it's appropriate for an erratum.  Further, it's too late: this behavior is only useful if older implementations follow it; you can't add extensibility after the fact. 
 
-- Jeff