Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
Hubert Kario <hkario@redhat.com> Mon, 14 August 2017 18:16 UTC
Return-Path: <hkario@redhat.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 A1B471323D3 for <tls@ietfa.amsl.com>; Mon, 14 Aug 2017 11:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 OxCclpjtlUsC for <tls@ietfa.amsl.com>; Mon, 14 Aug 2017 11:16:04 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD7D1323C8 for <tls@ietf.org>; Mon, 14 Aug 2017 11:16:04 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A5236B06A2; Mon, 14 Aug 2017 18:16:03 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A5236B06A2
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 482D86E507; Mon, 14 Aug 2017 18:16:03 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 14 Aug 2017 20:16:01 +0200
Message-ID: <2492694.vcgQpB2T86@pintsize.usersys.redhat.com>
In-Reply-To: <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com>
References: <1502460670.3202.8.camel@redhat.com> <CABcZeBNpJ5_03VZot_3hj7KHnJ8609HX-MY62n0+HLXoRg-+=Q@mail.gmail.com> <14329E27-DBCC-4A6F-BB4C-7CFAFD7ADF53@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1933778.G14JdJ80pV"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 14 Aug 2017 18:16:04 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Mo9S3_n988Tuu-HZdSaVhRcpEOA>
Subject: Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
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: Mon, 14 Aug 2017 18:16:06 -0000
On Friday, 11 August 2017 20:32:57 CEST Short, Todd wrote: > However, I argue that having TLS do significant padding for a protocol is > bad design for that protocol. It’s one thing if it’s a few padding bytes, > but the example given was 1023 bytes of padding. the difference in processing that is equal to just few clock cycles is detectable over network[1] > Also as pointed out by Andrei Popov, the application needs to tell TLS how > much padding to apply, so either way, the application has to deal with > determining the padding length. Why not just make it part of the protocol > in the first place? The problem is not when the application adds padding. The problem is when the padding is removed on the receiver side. > But my final point is that we are ignoring the amount of non-TLS processing > that must be done on various message types (before the response is sent), > and THAT might be even more of a giveaway than the minuscule timing > difference due to counting padding in TLS. Sure, it can, and in most cases it will be. We are not talking about this situation. When you are careful on the application level (which is fairly simple when you just are sending acknowledgement message), the timing will still be leaked. 1 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html (very bottom) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record pad… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Short, Todd
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Ted Lemon
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Andrei Popov
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Short, Todd
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Short, Todd
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Daniel Kahn Gillmor
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Colm MacCárthaigh
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Ilari Liusvaara
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Colm MacCárthaigh
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record… Hubert Kario