Re: [TLS] Fresh results

Hanno Böck <hanno@hboeck.de> Thu, 03 December 2015 23:52 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870B31ACE19 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 15:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.898
X-Spam-Level: *
X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pkywoz3i7E1 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 15:51:58 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1791ACD34 for <tls@ietf.org>; Thu, 3 Dec 2015 15:51:58 -0800 (PST)
Received: from pc1 (0x3ec7a652.inet.dsl.telianet.dk [::ffff:62.199.166.82]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 04 Dec 2015 00:51:55 +0100 id 00000000000000AA.000000005660D59B.0000087B
Date: Fri, 04 Dec 2015 00:52:08 +0100
From: Hanno Böck <hanno@hboeck.de>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20151204005208.5b9aad75@pc1>
In-Reply-To: <CACsn0ckkqhmH82P=NOaRF9J+EYBf=4HwfaBXKMvkp2QGdmnqNA@mail.gmail.com>
References: <CACsn0cm41VD40tiwR-sO9piPu01rRkoWKPwHWCKcr5Z9id8kDg@mail.gmail.com> <20151201210257.64f1a7a5@pc1> <CACsn0ckkqhmH82P=NOaRF9J+EYBf=4HwfaBXKMvkp2QGdmnqNA@mail.gmail.com>
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="=_zucker.schokokeks.org-2171-1449186715-0001-2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PnYhOzJ2KoD1R0beJ9DGmVzdQIA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fresh results
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2015 23:52:00 -0000

On Thu, 3 Dec 2015 18:45:14 -0500
Watson Ladd <watsonbladd@gmail.com> wrote:

> On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck <hanno@hboeck.de> wrote:
> > 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)  
> 
> Can you describe the complete set of required countermeasures, and
> prove they work comprehensively? What if the code is running on shared
> hosting, where much better timing attacks are possible? What's
> shocking is that this has been going on for well over a decade: the
> right solution is to use robust key exchanges, and yet despite knowing
> that this is possible, we've decided to throw patch onto patch on top
> of a fundamentally broken idea. There is no fix for PKCS 1.5
> encryption, just dirty hacks rooted in accidents of TLS.

No disagreement here.

The thing is, we have a bunch of difficult options to choose from:

* Fully deprecate RSA key exchange.
The compatibility costs of this one are high. They are even higher
considering the fact that chrome wants to deprecate dhe and use rsa as
their fallback for hosts not doing ecdhe. ecdhe implementations weren't
widespred until quite recently. A lot of patent foo has e.g. stopped
some linux distros from shipping it.

* Separate keys for TLS 1.3 and TLS <= 1.2.
Complicated. Certificates are already too complicated for many people.
Do we really want to add more complexity by having different certs for
different TLS versions?

* Make sure proper countermeasures are implemented.
Also difficult. I just learned nss is not bleichenbacher-timing-safe.

Sounds like three bad options to me.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42