Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12

Ron Frederick <ronf@timeheart.net> Tue, 13 March 2018 15:17 UTC

Return-Path: <ronf@timeheart.net>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BD71252BA for <curdle@ietfa.amsl.com>; Tue, 13 Mar 2018 08:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 KBltsclTZRtj for <curdle@ietfa.amsl.com>; Tue, 13 Mar 2018 08:17:09 -0700 (PDT)
Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A4D124B0A for <curdle@ietf.org>; Tue, 13 Mar 2018 08:17:08 -0700 (PDT)
Received: by mail-pl0-x236.google.com with SMTP id w12-v6so11466102plp.4 for <curdle@ietf.org>; Tue, 13 Mar 2018 08:17:08 -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=Im5KT7fzXFtJsYQ0v2qP7jnYXOD1s7iOk6MRM1KZjKE=; b=YUku6Jxl/t6SLxN0V3PkQgBGQSzGCigC25TbubbWN3hgt5Jw7miDuH9pxWu83WgBT4 wRmVrpDeLltyt1M6IyQyUeSzbOcwN5y0pdNXWYeQA2zywIQkX9TVXyvLTLddlJBXMGrD uH6sitaPH5ioIvQm3NyhAAqA7bDW6qf9M2+zA=
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=Im5KT7fzXFtJsYQ0v2qP7jnYXOD1s7iOk6MRM1KZjKE=; b=L/IyqZymdAIU5vmv8lfTPBTJWfHy2Xx2tr+jjJg87j8ywFH1XdDg8F/u4AHu0Pxn4p BsQSy6q2P/QWSy2ly1Dve6/O513WeSxL/xwG08Hthc6dhU2sOsUfedUhRDGEMoqwyymU rN0PY5WaNKhEmnC981EbvXXZ2MpYQykZ1Xr0rUVaaqowuXlVcka3u9qIOF8VmciWoBog TQXJgdsVBh7znGFrkRAcwLuxA1Zu/oFzU6er+Qiir8G3Z239ECDWoFVB9nypmxIHdfiZ w9GvKpT7LyCM4bq6CR88EGT5djNlgXJVwnndznrglz5NCjzeht9TTMZ4zVbdRjJAHUJz jrBw==
X-Gm-Message-State: AElRT7FEOHMCSyiY9WSoQsDnxnFVhtzvbwJkwNTtF3gd7BqdIvQ+8RxD raxU9uYoa3vtJrqTlufxqRISwA==
X-Google-Smtp-Source: AG47ELvpkqB6VRwUThiu1qGdcOjf997trwcdPrXYhZk2yLC4y+qGfolUh4oEVvk/zAq2eR37qwa87w==
X-Received: by 2002:a17:902:7b85:: with SMTP id w5-v6mr894626pll.131.1520954227485; Tue, 13 Mar 2018 08:17:07 -0700 (PDT)
Received: from [10.17.100.17] ([155.64.23.33]) by smtp.gmail.com with ESMTPSA id b21sm980548pfn.145.2018.03.13.08.17.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 08:17:06 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Ron Frederick <ronf@timeheart.net>
In-Reply-To: <CADPMZDDXi_h1uXzWJy37HXMrogQxJ5+Sd-G7ZZzfZJX_s390TA@mail.gmail.com>
Date: Tue, 13 Mar 2018 08:17:04 -0700
Cc: "curdle@ietf.org" <curdle@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E223CA3D-EED6-42E8-A013-BAD2A0490C2C@timeheart.net>
References: <4C40F019-21FB-46AC-95D3-CC94BB976AAB@akamai.com> <12087.1520816187@eng-mail01.juniper.net> <CADPMZDCwRN-GHXhAe=-xPFHMnUBN39UWmENGNUeLbFkneEAgcA@mail.gmail.com> <17856.1520829824@eng-mail01.juniper.net> <CADPMZDBnG1hv5D74vLv2bXqxZjceJgHQ9oYrufKHskLdV7nRSQ@mail.gmail.com> <28093.1520848786@eng-mail01.juniper.net> <40465B0B-FED4-4C16-A5C3-7E2C04E1B666@timeheart.net> <CADPMZDDXi_h1uXzWJy37HXMrogQxJ5+Sd-G7ZZzfZJX_s390TA@mail.gmail.com>
To: denis bider <denisbider.ietf@gmail.com>, "Mark D. Baushke" <mdb@juniper.net>, "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/dYbKo55FnuqSSK9PtVnW7i09mkY>
Subject: Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2018 15:17:10 -0000

On Mar 12, 2018, at 9:28 PM, denis bider <denisbider.ietf@gmail.com> wrote:
> Yes - this was the "mpint" idea that Mark broached. In SSH, the "mpint" type is used to encode a signed integer, and prepends the \0 byte if the value is positive and its high bit is on. This is necessary to distinguish the positive value from a negative one.
> 
> As far as I know, there does NOT exist any SSH implementation that would require such an erroneous encoding for an RSA signature.
> 
> If such an implementation did exist, it would fail to validate a very large proportion of valid signatures as currently generated by most SSH servers and clients. Unless my assumptions about RSA are incorrect, a very large proportion of signatures, e.g. 1/3 - or up to 1/2 depending on the modulus - will have the high bit set.
> 
> An implementation that would incorrectly require a signed encoding (like "mpint") would be immediately discovered in development. I have not seen it in practice.

If an implementation did a byte-wise compare of the signature, I agree that this would be discovered very quickly. However, a byte-wise compare would also trigger interoperability failures with implementations which strip leading zeroes. If there are implementations stripping leading zeroes in some cases without triggering interoperability failures, I don’t see why adding zeroes would would be any less likely, especially if code such as the “mpint” conversion was improperly reused. If the bytes are converted back to an integer before being compared, the comparison would succeed in either of these cases, while if they were compared as byte strings, both would fail.

> What I cannot say is how many implementations might ACCEPT a signed encoding if it is sent. If they do, I have no idea how many extra zeros such implementations might accept. It might be that there exist implementations (perhaps including ours!) that will accept an arbitrary number of leading zeros. Perhaps there may be so many zeros as to fill up to the maximum size of the SSH packet the implementation accepts.
> 
> If they do, though, I'm not aware of an attack that could be mounted based on that, and it won't arise as a compatibility issue. So I think it's not worthwhile to mention.

I think the important thing here is to make sure the text is very clear that the _correct_ encoding is an unsigned fixed-length byte string with a length matching that of the RSA modulus n, as described in RFC 3447 section 8.2. On the verification side, I would actually be ok with removing the “MAY” (and the sentence prior to it) entirely, but if we do keep it I’m not sure why the text should limit things to only shorter encodings.
-- 
Ron Frederick
ronf@timeheart.net