Re: [TLS] Fresh results

Yoav Nir <ynir.ietf@gmail.com> Thu, 03 December 2015 20:47 UTC

Return-Path: <ynir.ietf@gmail.com>
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 306FB1AC3E3 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 12:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, 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 i1HjwJJL4N0b for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 12:47:57 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2191AC3D8 for <tls@ietf.org>; Thu, 3 Dec 2015 12:47:57 -0800 (PST)
Received: by wmww144 with SMTP id w144so38824797wmw.0 for <tls@ietf.org>; Thu, 03 Dec 2015 12:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FNbkbHpBmtUllxpNtKEUvaKVdUAH7qATyzUfhXpoYVk=; b=o+N8YTupm97Rt2nCKo86ycg+0OQZN6fkNWdqrIu7H8qDaOA0nlAU7K+PtOr3U0Gxy/ IT9mx7UVXmbIq6bE3nCMOjATPtlF+xYKxoCx6Zv3c6+wyvXlLzgFq4AhXcvQ0X5pciC6 HpbK3dC7NVWz3ytooBxaVbZln/LwGuXLUvbdtB/tYZncyUpYc64uNoPXhY1vvGCyNEA2 kNaDBcTzcdb2zo37q74EArxcJcYjDupAAEvAaBDaE8b6rRXK37QAPhAIU/s52m4xaL0t mSI5uwsw49iu74bQ0D06NgesXysPh9mlcLz9psyBXPb3/Tn6xke+GPP/CRjlofCnnG6m +v2w==
X-Received: by 10.194.200.5 with SMTP id jo5mr13208676wjc.79.1449175675996; Thu, 03 Dec 2015 12:47:55 -0800 (PST)
Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q9sm9189489wjo.9.2015.12.03.12.47.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 12:47:55 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CANOyrg9AwQHfjZssf0c_=hfHvwLAuq2kFZwkOM7d8tHoHjaQ1A@mail.gmail.com>
Date: Thu, 03 Dec 2015 22:47:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com>
References: <CACsn0cm41VD40tiwR-sO9piPu01rRkoWKPwHWCKcr5Z9id8kDg@mail.gmail.com> <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> <CANOyrg9AwQHfjZssf0c_=hfHvwLAuq2kFZwkOM7d8tHoHjaQ1A@mail.gmail.com>
To: Fabrice Gautier <fabrice.gautier@gmail.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZpjRjvRmTRMDEzMIYk6Kd_DZ4pw>
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 20:47:59 -0000

> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:
> 
> On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>> On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote:
>>> On Tue, 1 Dec 2015 14:28:49 -0500
>>> Watson Ladd <watsonbladd@gmail.com> wrote:
>>> 
>>>> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls
>>>> 13QuicAttacks.pdf
>>>> 
>>>> 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.
>> 
>> The interesting result of the paper is:
>> "Even though this limits the
>> practical  impact  of  this  attack,  it  demonstrates  that  simply
>> removing a legacy algorithm from a standard is not necessarily
>> sufficient to protect against its weaknesses."
>> 
>> Even though the attack does not work for current implementations it
>> underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get
>> any advantage from the better algorithms in TLS 1.3. You are as safe,
>> as if you'd be using TLS 1.2.
>> 
>> That can be claimed to be trivial result given that it is underlined on
>> almost every paper that describes a cross-protocol attack, but it is
>> not still grasped by the engineering community. There have been
>> described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5
>> by Yu et al., TLS between ciphersuites starting by Wagner and
>> Schneier), but still we reuse keys between protocols.
> 
> Can we solve that problem generically by having TLS implementations
> use different certs for different TLS version, and have an indicator
> in the certs to indicate which version(s) they are for ?

That’s a heavy-handed approach that requires servers to have multiple certificates and new selection logic.

Wouldn’t it be better to mandate that if your TLS implementation supports both TLS 1.2 and TLS 1.3 it should take actions necessary to mitigate the bleichenbacher attack?

In fact, if you don’t care much about very old browsers, isn’t it possible today to mandate that the TLS implementation not use RSA keying? That way the oracle is gone.

Seems better than requiring web server administrators to acquire two certificates.

Yoav