IETF Logo Mail Archive

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:07 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 A6BF91323CA for <tls@ietfa.amsl.com>; Mon, 14 Aug 2017 11:07:03 -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 aAmwmDZ2OzAR for <tls@ietfa.amsl.com>; Mon, 14 Aug 2017 11:07:02 -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 80B901323C9 for <tls@ietf.org>; Mon, 14 Aug 2017 11:07:02 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F1232686AA; Mon, 14 Aug 2017 18:07:01 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F1232686AA
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx03.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 54EFA5D967; Mon, 14 Aug 2017 18:06:59 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 14 Aug 2017 20:06:57 +0200
Message-ID: <1708503.gcSoZQpuhk@pintsize.usersys.redhat.com>
In-Reply-To: <DM2PR21MB0091750568F7FDBF1939F7B88C890@DM2PR21MB0091.namprd21.prod.outlook.com>
References: <1502460670.3202.8.camel@redhat.com> <CADh2w8QexuvQtXyOsj3WkiPf+2YjH8yFhR7Wj3Ek+b=U3Bb3Fg@mail.gmail.com> <DM2PR21MB0091750568F7FDBF1939F7B88C890@DM2PR21MB0091.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4110553.B2nBj1sAOJ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 14 Aug 2017 18:07:02 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0zT4c0-zoruUDuNGutKtp6EacMQ>
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:07:03 -0000

On Friday, 11 August 2017 19:04:05 CEST Andrei Popov wrote:
>   *   I don't argue with this but this is not the approach TLS 1.3 took. It
> provides a generic padding mechanism to be used across application
> protocols.
> At some point I thought we said that the TLS 1.3 padding
> mechanism was supposed to be application-driven (in the form of
> application-provided policy or simply desired pad size), which would mean
> that the application has to be involved anyway. 

Problem is, that the application doesn't know how much time did processing of 
the message took (even if it gets the information that the received message 
was padded, which is not possible with current common library APIs).

So even if the application takes exactly as much time to process a long 
request as it does to process a short request, the length of that processing 
will leak.

-- 
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

v2.23.0 | Report a Bug | By Email