Re: RFC 4253 possible errata

[Ron Frederick <ronf%timeheart.net@localhost>]

Hi Mark,

On Jun 21, 2017, at 12:32 PM, Mark D. Baushke <mdb%juniper.net@localhost> wrote:
>>> 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.

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


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

[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
ronf%timeheart.net@localhost