Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 15 December 2017 17:02 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33B1200CF for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 09:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 NJE9-RStNiGK for <tls@ietfa.amsl.com>; Fri, 15 Dec 2017 09:02:24 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F6B127241 for <tls@ietf.org>; Fri, 15 Dec 2017 09:02:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 1A12397B65; Fri, 15 Dec 2017 19:02:23 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id LNfA0KVaQFyM; Fri, 15 Dec 2017 19:02:22 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BAFB727F; Fri, 15 Dec 2017 19:02:19 +0200 (EET)
Date: Fri, 15 Dec 2017 19:02:19 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Nikos Mavrogiannopoulos <nmav@redhat.com>, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20171215170219.GA17423@LK-Perkele-VII>
References: <CAAF6GDeeo2xjv1Xu7SFXVZ_zM=XUVJHT=eqH4_-G3+4UHsfvgg@mail.gmail.com> <CACsn0cmMbbT1iAfmxnXHe00dNiqBMyoNkk7e2CyTKWrcdRTtcQ@mail.gmail.com> <CAAF6GDf+GxToBAN83O3NtLO4zJ-8Qax8KjMCGhXv_EhY+NDsKg@mail.gmail.com> <20171215020116.04f9ae15@pc1> <CADh2w8TDJxaruU0M2B1kXsLDzopZBpha0_T1cT8NcMqo0S29Gg@mail.gmail.com> <CAHbuEH4CDdQyNdwK=JYLkw_tK+3u=GKeEs0EUt2byoVUwekqCA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHbuEH4CDdQyNdwK=JYLkw_tK+3u=GKeEs0EUt2byoVUwekqCA@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uvZKUXen1WB1EtW3yqe8OEsZVv0>
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 15 Dec 2017 17:02:28 -0000

On Fri, Dec 15, 2017 at 11:47:54AM -0500, Kathleen Moriarty wrote:
> 
> Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS
> 1.2 and prior? I haven't noticed any discussion on that previously. Is
> it just the code base and not those using it being unwilling to
> upgrade supporting libraries?
> 
> >From RFC8017:
> 
>    To avoid implementation weaknesses related to the way errors are
>    handled within the decoding operation (see [BLEICHENBACHER] and
>    [MANGER]), the encoding and decoding operations for RSAES-OAEP and
>    RSAES-PKCS1-v1_5 are embedded in the specifications of the respective
>    encryption schemes rather than defined in separate specifications.
>    Both encryption schemes are compatible with the corresponding schemes
>    in PKCS #1 v2.1.
> 
> And, yes, I know deprecation is very hard, but if there's been no
> effort, it should be considered as TLS 1.2 isn't going away anytime
> soon.

The problem is that handling a decryption fault in TLS 1.2 and prior is
hard. The TLS 1.2 RFC already discusses how to do that.

Basically, if decryption fails, you need to carry on as nothing had
happened, but then cause Finished MAC check to fail. In _constant_
time. Which is not easy, and even if your code looks constant time,
compiler "optimizations" can really ruin your day.


I think there should be a draft which formally deprecates RSA,
recommends the support to be removed (at least from server side)
and updates TLS 1.2 to change the MTI ciphersuite. Of course,
certain ("visibility") folks would scream about that.


-Ilari