Re: [TLS] Fresh results

Hanno Böck <> Tue, 01 December 2015 20:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 881931B2B54 for <>; Tue, 1 Dec 2015 12:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OZtCzwee5ecs for <>; Tue, 1 Dec 2015 12:03:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E90321B32CF for <>; Tue, 1 Dec 2015 12:02:49 -0800 (PST)
Received: from pc1 ( [::ffff:]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by with ESMTPSA; Tue, 01 Dec 2015 21:02:46 +0100 id 0000000000000037.00000000565DFCE6.00001A5A
Date: Tue, 01 Dec 2015 21:02:57 +0100
From: Hanno Böck <>
Message-ID: <20151201210257.64f1a7a5@pc1>
In-Reply-To: <>
References: <>
X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary=""
Archived-At: <>
Subject: Re: [TLS] Fresh results
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: Tue, 01 Dec 2015 20:03:25 -0000

On Tue, 1 Dec 2015 14:28:49 -0500
Watson Ladd <> wrote:

> This one looks very nasty to fix. Short of disallowing the use of RSA
> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I
> don't see a good fix. I haven't read this paper in detail yet.
> Cross-protocol attacks are the gift that keeps giving.

Correct me if I'm wrong, but as I understand the result (and I had one
of the authors explaining it to me a few days ago) the problem appears
only if you have a TLS 1.2 implementation with an RSA keyexchange that
is vulnerable to a bleichenbacher attack. If it is not then you're fine.

So as long as you make sure you implement all the proper
countermeasures against that you should be fine. (Granted: This is
tricky, as has been shown by previous results, even the OpenSSL
implementation was lacking proper countermeasures not that long ago,
but it's not impossible)

Deprecating the RSA keyexchange just became a bit harder with Google's
intent to deprecate DHE in Chrome and use RSA as the fallback if the
host doesn't do ECDHE.

Hanno Böck