Re: [TLS] Reducing record expansion overhead allowance

Fabrice Gautier <fabrice.gautier@gmail.com> Mon, 21 July 2014 04:49 UTC

Return-Path: <fabrice.gautier@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 1CC5B1B2D67 for <tls@ietfa.amsl.com>; Sun, 20 Jul 2014 21:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 04kQzKUsf6tC for <tls@ietfa.amsl.com>; Sun, 20 Jul 2014 21:49:04 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DC21B2D5B for <tls@ietf.org>; Sun, 20 Jul 2014 21:49:04 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id hz1so8929878pad.8 for <tls@ietf.org>; Sun, 20 Jul 2014 21:49:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3gqKOqmaIYPKzbfX1zkqH1LYO/OEKW+P8FZpPnYoBGM=; b=t2ZfFBe8XseOCwfzsZ5p2jV43mEJfhha2PUV4G+qSNL8Y/0IFFnkY/ZaGWxFJyPC8D kHjcnygWdJ/6esDJLVGcTv4dTyCQ55Iv6plsiU0fvwndzGhhIQ3XptrtpbLRRJnR6ni3 Gh22SFDEdwFyROAAUTys8MLUhH1xhq1vpVpycQuCyujvCL/pGn8V/1HgaX89XCJOA+hi q7MgW1D65PF5wlgU2vvuDCqUwxcPzlO1UVrbw5QIhx/CDR16kA0ypiWxZOg2nRnj4L/x PR7jNkvCTXWxmdhfHGxN3ehMK1jFTHJ20x3mjU3FebwZXqT3Lk0yUc3tjvrbm9yoJmYJ uImg==
X-Received: by 10.68.225.74 with SMTP id ri10mr7293450pbc.116.1405918143703; Sun, 20 Jul 2014 21:49:03 -0700 (PDT)
Received: from [10.0.1.7] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id sh5sm12760569pbc.21.2014.07.20.21.49.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 21:49:01 -0700 (PDT)
References: <CABcZeBODbabpOUgb431X3Xz_fB1KK8wn8-SMJgYZVE2V3oCLow@mail.gmail.com> <CANeU+ZCX4wGOPytP3qO80Q+6yq=TFCM0Xi9SMmxdMrveDv8ZCA@mail.gmail.com> <CABcZeBMt++Oc4-UNiXuHX=mY0CEw_DorNLCdRLBsKdj5gu=oBg@mail.gmail.com> <CANeU+ZA8zgU2FK5KOK2i9G0eVGPb5XVVq2PRUNVdMDA0BH285A@mail.gmail.com> <CABcZeBMzYbHL8STfZJRRAr+wJrknH_SeBKcM5jj7QFNCv1RkYg@mail.gmail.com> <CANeU+ZBPvGJHjtUX0DE0peD==b=Si+ByTao2PgpSYKxc8egO-Q@mail.gmail.com> <53CC8513.8040808@fifthhorseman.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <53CC8513.8040808@fifthhorseman.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBB08009-AA6A-41C2-ABC0-3E0BFF7820DB@gmail.com>
X-Mailer: iPad Mail (11D201)
From: Fabrice Gautier <fabrice.gautier@gmail.com>
Date: Sun, 20 Jul 2014 21:48:59 -0700
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X7zq4snhfaJygAtkn4Np-jgycKQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Reducing record expansion overhead allowance
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: <http://www.ietf.org/mail-archive/web/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, 21 Jul 2014 04:49:06 -0000

> On Jul 20, 2014, at 20:12, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> [reordering for chronological sanity]
>> On 07/20/2014 12:21 PM, StJohns, Michael wrote:
>>> On Sunday, July 20, 2014, Eric Rescorla <ekr@rtfm.com> wrote:
>>>> On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael <msj@nthpermutation.com wrote:
>>>>> On Sunday, July 20, 2014, Eric Rescorla <ekr@rtfm.com>  wrote:
>>>>> 
>>>>> I believe the consensus here was to have padding be done separately.
>>> 
>>>> You mean as part of the plain text?
>>> 
>>> From the perspective of the AEAD algorithm, yes.
>> 
>> So then not really a TLS issue, but has to be supported by each application
>> and is transparent to TLS?   Ok - Thanks.
> 
> No, i don't think that was the intended meaning.  I think padding should
> be made available within TLS, but applied directly on the cleartext; the
> padded form of the cleartext is what is fed to the cipher.

0
So, if I understand, we would have something like:

TLSPlaintext: what the application sends
TLSPadded: the same with added padding, input of the AEAD engine
TLSCiphertext: output of the AEAD engine, what goes on the wire. 

In that model, TLSPadded basically replace TLSCompressed of TLS 1.2, and, to go back to the original issue, your allowed overhead should probably stay the same.

> 
> Unpacking the nuances i recall from Denver:
> 
> * padding is probably most correctly and effectively done at the
> application layer, since the application itself has an understanding of
> what its common usage patterns are, and how to frame a plausible
> anonymity set as a padding target.
> 
> * but in practice, most applications (and most implementations) are
> likely to just slap TLS on top of a cleartext protocol "for security",
> and not think much more about it.
> 
> * some application layers themselves may not have the means to produce
> and consume the padding needed within the application cleartext.
> 
> * some (imperfect) level of resistance to traffic analysis is probably
> achievable with a simple policy applied at the TLS layer, without
> application layers having to do anything but flip a switch.  This is
> much more likely to happen for any given application than detailed analysis.

> Given these constraints, TLS is probably the best place to provide the
> possibility of padding.
> 
> Defining reasonable and comprehensible padding policies/profiles is a
> lot more work that will also need to be done, but we should be able to
> define the mechanism within TLS without too much complexity.
> 
>    --dkg
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls