Re: RFC 4253 possible errata

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Hi Ron,

Ron Frederick <ronf%timeheart.net@localhost> writes:

> Hi Mark,
> 
> On Jun 21, 2017, at 11:20 AM, Mark D. Baushke <mdb%juniper.net@localhost> wrote:
> > While working with the IETF AD Eric Rescorla <ekr%rtfm.com@localhost> 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.
> 
> [Ron] I don’t understand the “p-2” here. Is that a typo? 

Yes, I guess I should be careful when I touch-type numerals. It is
intended to be p-1 in both cases.

> Also, if you want to convert from the closed range [1, p-1], shouldn’t
> that to be to an open range of (0, p), which would correspond to “0 <
> z < p”?

Yes.

That is the error. I believe it should either have been written as [2,
p-2] or (1, p-1).

If we look at other sources such as NIST SP 800-56A revision 2, page 36
section 5.6.2.3.1 we see the verification is [2, p-2] which is also used
in RFC 7919.

> > 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.
> 
> [Ron] I see RFC 7919 refers to a closed range [2, p-2]. This would be
> a change from what is allowed by RFC 4253 today.

Yes.

> > 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.
> 
> [Ron] In asyncssh, the test I’m doing on e & f is “1 <= e < p” and “1
> <= f < p", which is essentially the half-open range of [1, p) that is
> equivalent to the closed range [1, p-1] listed in RFC 4253.

Okay.

This implies that there would need to be an implementation change if we
agree that RFC 4253 use of a closed range is an errata because an open
range was intended. Or, we could agree that narrowing the range is in
the best interests of the DH key exchange.

	-- Mark