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

denis bider <> Tue, 13 March 2018 04:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 258B81243F6 for <>; Mon, 12 Mar 2018 21:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4rZE0qLlP4JW for <>; Mon, 12 Mar 2018 21:28:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85BEE124234 for <>; Mon, 12 Mar 2018 21:28:21 -0700 (PDT)
Received: by with SMTP id o184so8934962qkd.13 for <>; Mon, 12 Mar 2018 21:28:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CcbyRiEsghLn14o6qhxB1h6MJrRxsIF569tkdrwM9P4=; b=TqFh1FqpuY0VxI9Ss8+IH+GIU+db90/OUSKiVpZaT4TBsRhbrKCOyrhFLckhaFbO6Q DlWe+99/DekCFIUw7g1O/Jw0TJ3lxMKTBbGgEhZQhXs+J11kh3Nf4+vAHSGjZLQcs53j z1itOTRvX4MoKrJfanCkRZQfLQg4pozjf5TB96mpzOXyjBg3DInr+VSITEFjqkLHH5V6 YAAhcPIf9MD10d/XtIGvQ6WEFDnGWZgIZeIFYyG1ztWfJWjN6Ei9SjOEG+cVpuC1UOPt VNx6rsVoPUVWidpfqeV0sjN0DzV6pBa58p11h2CjZ3gB3eLHDkQTIWxzpMXG5Y7JVdd6 aG6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CcbyRiEsghLn14o6qhxB1h6MJrRxsIF569tkdrwM9P4=; b=YNWZVeJgjoaCGR14E14IfFPXEnXM4hujOisRTPKcPb49HmtNTnG1oK7KMqChpXjjnq cSuRO0L/HHik8RQej+bH9pvjEvKngcZg68BEhqz0AN7GpU2RlXjI5nopYv/ApBgClyY6 v7eEe/H3vrcEiGlSV7oDXPaNV7Vnye6pNOHHlRD+STJb8OV2G5XyFY7d0/pGbhm/Hrri QQujzNlaMMxIbmQKfDuR7ZZmr14j5hKqrVrpYQRJIewFXpscaNTpce7FslTkI1gAipoT dDaw/KWTyQd0T2eWp2L1ZOUJmAWOuJ+25t/2oVWJnDN4LDcYNty5BuVtfhe668zUiMml o/rw==
X-Gm-Message-State: AElRT7HijCOggFLKSyG6r7oUOIePv03nZX/E5rGcKTdQHIlJLRDUT1pz q3JTbYgGiqWemWzIRd6gdztj3wwujrtGK5Md0Is=
X-Google-Smtp-Source: AG47ELunMtEtqlzlIUIxjke0sShUGUF5kYfUf4bNIAVabP2OadkeD4P6cS3e9fq3cypQ7VvOokYHhKkhZrAQGyumP5U=
X-Received: by with SMTP id c203mr15602872qkb.351.1520915300549; Mon, 12 Mar 2018 21:28:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 12 Mar 2018 21:28:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: denis bider <>
Date: Mon, 12 Mar 2018 23:28:20 -0500
Message-ID: <>
To: Ron Frederick <>
Cc: "Mark D. Baushke" <>, "Salz, Rich" <>, "" <>
Content-Type: multipart/alternative; boundary="001a114a9bb2390903056743b032"
Archived-At: <>
Subject: Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Mar 2018 04:28:24 -0000

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.

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.

On Mon, Mar 12, 2018 at 8:01 PM, Ron Frederick <> wrote:

> Agreed on MAY here instead of SHOULD.
> One of the original e-mails on this thread also mentioned prepending a
> leading 0x00 byte in cases where the high-bit of the first octet is set.
> I’m not sure we want to ever allow that. is anyone aware of any existing
> implementations that do that today, incorrectly thinking this value was
> supposed to follow the rules for encoding an “mpint” instead of a
> fixed-length octet string?
> On Mar 12, 2018, at 2:59 AM, Mark D. Baushke <> wrote:
> > Hi denis,
> >
> > Argument #3 works for me.
> >
> > MAY is best. SHOULD lets broken implementations continue to be broken.
> >
> > Thank you for your responses.
> >
> >       Enjoy!
> >       -- Mark
> >
> > _______________________________________________
> > Curdle mailing list
> >
> >
> --
> Ron Frederick