RFC 4253 possible errata

Hi Folks,

While working with the IETF AD Eric Rescorla <[email protected]> doing the AD
review of draft-ietf-curdle-ssh-modp-dh-sha2, the topic came up of
validation of the Diffie-Hellman public key on both client and server
(peers).

The RFC 4253 Section 8 writes:

|8.  Diffie-Hellman Key Exchange
|
|   The Diffie-Hellman (DH) key exchange provides a shared secret that
|   cannot be determined by either party alone.  The key exchange is
|   combined with a signature with the host key to provide host
|   authentication.  This key exchange method provides explicit server
|   authentication as defined in Section 7.
|
|   The following steps are used to exchange a key.  In this, C is the
|   client; S is the server; p is a large safe prime; g is a generator
|   for a subgroup of GF(p); q is the order of the subgroup; V_S is S's
|   identification string; V_C is C's identification string; K_S is S's
|   public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's
|   SSH_MSG_KEXINIT message that have been exchanged before this part
|   begins.
|
|   1. C generates a random number x (1 < x < q) and computes
|      e = g^x mod p.  C sends e to S.
|
...elided...

|   Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be
|   sent or accepted by either side.  If this condition is violated, the
|   key exchange fails.

...elided...

The z in range [1, p-1] notation, specifies a closed interval which
includes the end points which is equivant to 1 <= z <= p-1. The (1, p-1)
notation specifies an open interval which excludes the endpoints 1 < z <
p-2.

Eric noted that https://tools.ietf.org/rfcmarkup?rfc=7919#section-5.1
uses open endpoints.

Eric suggested that my draft should include text that is similar to the
ext in the RFC 7919 to correct this errata.

Before I make such a change, I wish understand if what folks have been
using for the test in their implementations and get a consensus on such
a change.

	Thank you,
	-- Mark