Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange?

David Benjamin <> Wed, 12 February 2020 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03BD7120824 for <>; Wed, 12 Feb 2020 09:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-ySedpIRdey for <>; Wed, 12 Feb 2020 09:12:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBADE120823 for <>; Wed, 12 Feb 2020 09:12:22 -0800 (PST)
Received: by with SMTP id y5so1532568pfb.11 for <>; Wed, 12 Feb 2020 09:12:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YA9/ObPb8OxW8vHd31o8GdkzpeTi+ayM8Tn7oiK8QVw=; b=NIX6mA2ogeMxi/yW+NAF6WARXBb1sYzSLMDEX1QuxAk5Yk3cgem/osVWIMStywlgU3 R19DZ+jusOWzF6sFCau4bLSVh+UH5asBv/mV3cz0mr5LZAaTWynGM4SQabQu5i/IoQVG MuGbplfNmW1hMqGR8jTAhiROcAV+6MS4GW+ro=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YA9/ObPb8OxW8vHd31o8GdkzpeTi+ayM8Tn7oiK8QVw=; b=OMdA9v/Sj44TSVhu/v+8T9fVQn5elxPucKS01aEmaP7Noy9P+iConGQbBByFvv2vz4 PwjCUC852v6s6ZB0LM3+E3+qouxmnn5WugsK/904V8QF0LQAne1QSczA4kyelXA+mpLT MyhT/w0w2SavY9vnnjpAQGLNWA8LoLcnOsXEpCGufjZgi+IxFNX4GhSxMmN1EtjPRV2r K2OjdNKki13Rz+Jf4xL9dgNzKDrIA4aYH+CLiMDIzUCtWQze/3fgwwK0fdasvrnWdVoe dCf0MQTV9K6C8rPYehFw2yZBAEGRyZOh1Z5FhOlE9pvJEGoUUoym4ONKUZHPaLjeSf5u lK9g==
X-Gm-Message-State: APjAAAVvfnXFuMmRbCdF3ZS9AkLC4lJeGGXeYyoudq7UW6arKUkx5xTp jFssYS9qN24D9DZhmyl10LjSYn9cMVzqhzazQ2XT
X-Google-Smtp-Source: APXvYqxaa9okevL7cL5BLZVstDeimbBpQxuQ7Mw8vREfKTzlsFzGz8qgBGiAnULDOTa4o7l55yfW++WLV1JP3UA/qRs=
X-Received: by 2002:aa7:9a0b:: with SMTP id w11mr12697662pfj.4.1581527541951; Wed, 12 Feb 2020 09:12:21 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 12 Feb 2020 12:12:05 -0500
Message-ID: <>
To: Peter Gutmann <>
Cc: M K Saravanan <>, "<>" <>
Content-Type: multipart/alternative; boundary="00000000000057a4f8059e64130b"
Archived-At: <>
Subject: Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2020 17:12:24 -0000

On Wed, Feb 12, 2020 at 11:10 AM Peter Gutmann <>;

> M K Saravanan <>; writes:
> >Is this allowed?  i.e. stripping the leading zero of the RSA signature and
> >marking the length as 255?   It is not clear to me from the RFC5246
> whether
> >it is allowed or not.
> It's not allowed according to the spec but a number of implementations do
> it
> because their underlying bignum libraries perform leading-zero truncation,
> so
> you're better off allowing it to avoid breakage.

For web use cases, this does not appear to be necessary. BoringSSL and
Chrome do not accept such signatures and have not for around five years
now. (Possibly longer. I do not know off-hand what Chrome's behavior was
when it used NSS.) I don't think I've ever seen a report of problems with a
website, and the specification quite clearly says to reject those
signatures. The robustness principle sounds plausible at face value, but I
think we now have the experience to know otherwise.

Note that bignum libraries that perform leading-zero truncation are
unlikely to be suitable for cryptography anyway. Signatures are public
values, but if you're implementing RSA decryption and care about side
channel attacks, fixed-width in-memory representations and serialization
functions are mandatory.