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

[denis bider <ietf-ssh3%denisbider.com@localhost>]

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


----- Original Message -----
From: Niels "Möller" 
Sent: Friday, November 13, 2015 02:37
To: Peter Gutmann 
Cc: denis bider ; ietf-ssh%netbsd.org@localhost ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.farrell%cs.tcd.ie@localhost ; jon%siliconcircus.com@localhost ; djm%mindrot.org@localhost ; Max Horn 
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:

> Niels Möller <nisse%lysator.liu.se@localhost> writes:
>
>>Send 0, ignore received value, would have made it actually useful.
>
> Can we get any figures on what effect making it nonzero would have?

I think my implementation will disconnect.

Anyway, if we do a general smallish update, it would make sense to fix
this (not sure in which form, note in the algorithms update rfc, or an
errate on hte old rfc). And simply say that until any of the future
extensions are specified, implementations should accept and ignore
non-zero values for this field.

That will make our lives a little easier a few years from now.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.