Re: [TLS] Using RSA PSS in TLS

Watson Ladd <> Thu, 15 January 2015 18:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3E631B3037 for <>; Thu, 15 Jan 2015 10:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.3
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sf0CxGyLE5ae for <>; Thu, 15 Jan 2015 10:38:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D9971B3032 for <>; Thu, 15 Jan 2015 10:38:40 -0800 (PST)
Received: by with SMTP id v1so8095229yhn.1 for <>; Thu, 15 Jan 2015 10:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lmNACsSNEYu/qpyuAQ1JFxFstdBJlsGXp6PVA04P4w4=; b=GVqB5Iv1qSiVS6QSETmz9FlMvhfskhyRZhZ0BBb5+/1KNHaAc9SI2cR9b5lvzn8sxP ood9xJAkU+6oxGEFwWLgU6SvHmhdkGX1PVQbVyr8TryKpfpj6gQmPQulZypaLaX5MALj 5+3xq1FqsB56ZX6xj+ezw/I7X0Uh4VmNFSOKytTscEX7kevCHpWINXcMAWY7yGYUID5A g/nHHG2B2sFbg19U5Qkyf6xD2Y9Ew7I1JtnN7kYMcRIevCeT9gEsQX5EKZPDGAkfEmc4 B4sUy5Ip/XrM+RwQpTgWee/qINOcUfHezfn/uPkl4cPA/IKiYv+HczY7IVOdSxqV1tvI Depw==
MIME-Version: 1.0
X-Received: by with SMTP id 46mr6991068yho.138.1421347119442; Thu, 15 Jan 2015 10:38:39 -0800 (PST)
Received: by with HTTP; Thu, 15 Jan 2015 10:38:39 -0800 (PST)
In-Reply-To: <20150115013149.0185bea4@pc>
References: <> <> <> <20150115013149.0185bea4@pc>
Date: Thu, 15 Jan 2015 10:38:39 -0800
Message-ID: <>
From: Watson Ladd <>
To: Hanno Böck <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Using RSA PSS in TLS
X-Mailman-Version: 2.1.15
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: Thu, 15 Jan 2015 18:38:47 -0000

On Wed, Jan 14, 2015 at 4:31 PM, Hanno Böck <> wrote:
> On Wed, 14 Jan 2015 15:32:42 +0100
> CodesInChaos <> wrote:
>> I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
>> of PKCS#1v1.5 signatures.
>> I'm not aware of any attack against  PKCS#1v1.5 signatures, they
>> merely lack a security proof.
> Bleichenbacher's signature forgery attack [1], which has recently been
> re-discovered in combination with some ASN.1 issues under the name
> BERserk [2].
> Sure, these are "mere implementation issues". You can do PKCS #1 1.5
> signatures right - just like you can do PKCS #1 1.5 encryption right.
> It's just that people did it wrong multiple times. I don't see simliar
> risks with PSS, it's the much more robust solution.

You *cannot* do PKCS 1.5 encryption right. The countermeasures to
Bleichenbacher depend on enforcing additional structure on the
messages, which SSL imposed by accident. As everyone should know, many
implementations still do not get this right. (Can't name which ones,
but even if they make the check, they may expose timing channels that
are exploitable: there was a German PhD thesis a year or two ago that
investigated exactly this, and broke some Java implementations).

Implementors are clearly not reading the documents we produce in a
more than cursory manner: RFC 2437 tells you exactly how to avoid
these issues, and refers to papers explaining how bad things can go.
That was in 1998! Yet we still see bugs in PKCS 1.5 signature
verification caused by not following the spec.

RSA-OEAP has similar error oracle issues, It's a moot
point because we aren't using an RSA encryption based method in TLS
1.3, but there is an obviously secure alternative in the ROM, namely a
variant of RSA-KEM, which doesn't have these implementation issues.

We need to think in terms of "how badly is the coder who writes things
going to mess up" when designing, and check that the actual deployed,
running code, is doing the right thing. The downgrade dance is an
example of something that should have been visible years ago. RC4
insecurity was known in 2001. POODLE is in a text document from 2004.
Encrypt-then-MAC was since 2000-20001, and we didn't properly fix it
for 13 years afterward.

In terms of the original thread necromancy, yes, the security
properties are different: one set has PFS. I'm not sure what
properties are being discussed, especially given that we now know
almost everything about TLS's actual security, that make changing

> [1]
> [2]
> --
> Hanno Böck
> mail/jabber:
> GPG: BBB51E42
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin