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

denis bider <> Wed, 14 March 2018 10:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26F641241F3 for <>; Wed, 14 Mar 2018 03:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Q3VnmgZKjeoC for <>; Wed, 14 Mar 2018 03:55:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 267D6129C51 for <>; Wed, 14 Mar 2018 03:55:57 -0700 (PDT)
Received: by with SMTP id g60so2862112qtd.11 for <>; Wed, 14 Mar 2018 03:55:57 -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=LMu45MzkTHaSPEut5g8jazEiNgqlITMuYCNYHIsezX0=; b=h6Owa9ri774x7Pb3GErkeyZs/o9zSVfKswj5tntqqf9TWpo3Mx8ddW0U2N6qcXMGXM +B0e1FI81KH/Mzj2TlxMLyO8gzREqnItNKxdbdi2Pp+E8vTc8ca78CzBzqNb+X0n4C3p dxkse140I91dJAuEdLpeXTi8HvstH/OMtvVP0LhuPw8UkDn6pbj4NfVnm4tXoIXhYMZs W/grs1OefRhDp61onEmrd3sQeuJSpWtF5ziUwtn8HfoIfrPl33xf5qb7dLzW0meoZlXB 8Z/Em8JNpe3o5zydOay538ftcLgf1O9TDZ9cogv4g3Q+I36g2QS8KHTJmLAL6qeg1It0 gngQ==
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=LMu45MzkTHaSPEut5g8jazEiNgqlITMuYCNYHIsezX0=; b=kEjgJ1+qrwDUTal5EFWTi6GZo6GjmUZjp5Z73sCv5GWholqfgPlO2Rh4FznSBhb3ck 8Wj1u003yTzqoDraEX6gnXKc0rW/8nAAY38Dl2vAqH5WdB/WS50IA2UYzuaww/USCdtu 54KxNCJUiym/2biPIgVh1q98gx5dJHZ5yxJQteEfVnE/OGRlWAAEF7yPpU+Iwbsz+UCD PuJCARDvSyBJNGykK1v2QnTcPmTC5GRq8+Cq8uH7SKEIa0uaUnMDdP6yAxC4A087PmWC gatklu5qZnKyNpi7Q5C+yj8+ihkEjo29+TloIXPl4SC+c3Ser11NYwHkIYW/wTrA/QFo uzgg==
X-Gm-Message-State: AElRT7GL/43460bLO3bHFlNg8KumbyNoXegk5f+cr9smxJzGO9HCJbrs faAP6+Eab9YJh4EkvjbnuN/JuloOzjM8elU8l60=
X-Google-Smtp-Source: AG47ELtlj5mAS2NMtnFXTn/GhckRbX36p5U3tUBI/QXxTyGfYGnw7sJFhG/+ZphGXdQjgs6/rhEPN7Y4/hV1cg2Gt6s=
X-Received: by with SMTP id 36mr6059873qth.224.1521024956027; Wed, 14 Mar 2018 03:55:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Mar 2018 03:55:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: denis bider <>
Date: Wed, 14 Mar 2018 05:55:55 -0500
Message-ID: <>
To: Ron Frederick <>
Cc: "Mark D. Baushke" <>, "Salz, Rich" <>, "" <>
Content-Type: multipart/alternative; boundary="94eb2c0d047c32e2a405675d380c"
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: Wed, 14 Mar 2018 10:55:59 -0000

> 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

I have a high degree of confidence that no such implementations exist.

The reason for this high degree of confidence is that certain older
versions of our software - some of which are still in use, despite our
attempts to get people to upgrade - had a bug which would be triggered by
overlong signatures. The bug is such that if it was ever triggered, it
would certainly be brought to us.

We have never received news of this bug being triggered.

> I’m not sure why the text should limit things to only shorter encodings.

Because the text is to warn implementers of existing practice, not
non-existent practice. :) As explained above, I have a high degree of
confidence that there are no implementations that send overlong signatures.

On Tue, Mar 13, 2018 at 10:17 AM, Ron Frederick <> wrote:

> On Mar 12, 2018, at 9:28 PM, denis bider <>
> 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