Subject: RFC 4253 possible errata

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 21 Jun 2017 11:20:05 -0700

Hi Folks,

While working with the IETF AD Eric Rescorla <[email-masked]> 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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 21 Jun 2017 12:32:00 -0700

Hi Ron,

Ron Frederick <[email-masked]> writes:

> Hi Mark,
> 
> On Jun 21, 2017, at 11:20 AM, Mark D. Baushke <[email-masked]> wrote:
> [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.

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

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

---

From: Ron Frederick <[email-masked]>
Date: Wed, 21 Jun 2017 11:41:35 -0700

Hi Mark,

> notation specifies an open interval which excludes the endpoints 1 < z <

[Ron] I don’t understand the “p-2” here. Is that a typo? 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”?

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

> using for the test in their implementations and get a consensus on such

[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.
-- 
Ron Frederick
[email-masked]

---

From: Ron Frederick <[email-masked]>
Date: Wed, 21 Jun 2017 22:31:02 -0700

Hi Mark,

> section 5.6.2.3.1 we see the verification is [2, p-2] which is also used

[Ron] Interesting. I just checked the OpenSSH code, and it looks like it is already enforcing [2, p-2], so that would support considering this to be an error in the RFC, and would also suggest I should change my implementation to avoid picking a value that OpenSSH would reject if I was doing a DH exchange with it.

> the best interests of the DH key exchange.

[Ron] If there’s a mix of implementations out there, that would argue that making all of them use the narrower range would be best. In additional to bringing this in line with RFC 7919, it would help to avoid a rare but possible interoperability problem.
-- 
Ron Frederick
[email-masked]