Re: RFC 4253 possible errata

Ron Frederick <ronf@timeheart.net> Fri, 23 June 2017 05:19 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C2126C23 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 22 Jun 2017 22:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Level:
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=timeheart.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDW7XET9yWlP for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 22 Jun 2017 22:19:39 -0700 (PDT)
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1816120721 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Thu, 22 Jun 2017 22:19:39 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 9375484DAD; Fri, 23 Jun 2017 05:19:37 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 3A05584DA0; Fri, 23 Jun 2017 05:19:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A6CAD84DDE for <ietf-ssh@netbsd.org>; Thu, 22 Jun 2017 05:31:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net
Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id m_ZfaAOrMvKO for <ietf-ssh@netbsd.org>; Thu, 22 Jun 2017 05:31:06 +0000 (UTC)
Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C281E84CDD for <ietf-ssh@netbsd.org>; Thu, 22 Jun 2017 05:31:04 +0000 (UTC)
Received: by mail-pg0-x241.google.com with SMTP id e187so1103840pgc.3 for <ietf-ssh@netbsd.org>; Wed, 21 Jun 2017 22:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cbrLFbC89qhf3PpoNGa4vgTnkyOF+F7gG9C8Qit/988=; b=aq1oUzHowdfdsR9Ck44zdn5+fQDsnM7ZX3MZtC+EpUKdviuXjaIYjXuBCgMwYGWoC2 5HPwPmHO6GToM7xiTr96dz2Bs1YZQcDWvl9h+0drmE2D8fyV1lgWx81Ye4SLDsJ+nzxS x41Qt2d4s0RA5vRAAx+U49Cm7tvr7XWUtYV4A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cbrLFbC89qhf3PpoNGa4vgTnkyOF+F7gG9C8Qit/988=; b=av+i/j+X2R2pA9EpnchuotODvIUKIshPmjTvtPye+4Lf7wuMAy4VUfcgvJDsKN8wk5 1ByJVyFYi9HzzjMWc/McWR2M6DK/xQIdPd3RYwA2jCdGsxn1hfdTOXhThDu7LokomBEF UxLkA4y7xsv4tOpc2R4uotFuZLlAbXbO8iSf3DkSpYlM9xdXpgOHEGTYo5X87DM3d0QO 1wtFMggAXuBwd6vx1sCmAsAxc7koIGYlYTuw62XQ/p1ojBd362QZ3PbsTG33RhMqJJHp 6Gx8Giyaa6axz9EAAxiZjHMoOPhbZgz9oxrgQwUN/TIIYhZhIfRFc40z8/hJVozl8U3E 36OQ==
X-Gm-Message-State: AKS2vOyQbCi3BoYVWPYnB+eq+DffYke4GjaHHjUPb5npjI1XxnEyaC15 yFvlP6Sf6nl7uUvaLQx8A0O8
X-Received: by 10.84.216.70 with SMTP id f6mr910129plj.79.1498109464256; Wed, 21 Jun 2017 22:31:04 -0700 (PDT)
Received: from 74-93-13-193-sfba.hfc.comcastbusiness.net (74-93-13-193-SFBA.hfc.comcastbusiness.net. [74.93.13.193]) by smtp.gmail.com with ESMTPSA id r129sm942402pfr.112.2017.06.21.22.31.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 22:31:03 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: RFC 4253 possible errata
From: Ron Frederick <ronf@timeheart.net>
In-Reply-To: <91495.1498073520@eng-mail01.juniper.net>
Date: Wed, 21 Jun 2017 22:31:02 -0700
Cc: Curdle WG <curdle@ietf.org>, SSH WG <ietf-ssh@NetBSD.org>, Eric Rescorla <ekr@rtfm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8921418C-1876-446B-8216-C29127B22B0A@timeheart.net>
References: <80212.1498069205@eng-mail01.juniper.net> <50A8EE09-4FB3-4272-956E-E280F90E01A9@timeheart.net> <91495.1498073520@eng-mail01.juniper.net>
To: "Mark D. Baushke" <mdb@juniper.net>
X-Mailer: Apple Mail (2.3273)
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list
List-Unsubscribe: <mailto:majordomo@NetBSD.org?subject=Unsubscribe%20ietf-ssh&body=unsubscribe%20ietf-ssh>

Hi Mark,

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