Re: [TLS] Reducing record expansion overhead allowance

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 21 July 2014 03:12 UTC

Return-Path: <dkg@fifthhorseman.net>
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 578131B2AB1 for <tls@ietfa.amsl.com>; Sun, 20 Jul 2014 20:12:28 -0700 (PDT)
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] 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 8ziUAzG6Kyev for <tls@ietfa.amsl.com>; Sun, 20 Jul 2014 20:12:26 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C01361B2B02 for <tls@ietf.org>; Sun, 20 Jul 2014 20:12:25 -0700 (PDT)
Received: from [10.0.1.131] (173-230-166-62.cable.teksavvy.com [173.230.166.62]) by che.mayfirst.org (Postfix) with ESMTPSA id 7FD21F984; Sun, 20 Jul 2014 23:12:22 -0400 (EDT)
Message-ID: <53CC8513.8040808@fifthhorseman.net>
Date: Sun, 20 Jul 2014 23:12:19 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
To: "StJohns, Michael" <msj@nthpermutation.com>, Eric Rescorla <ekr@rtfm.com>
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>
In-Reply-To: <CANeU+ZBPvGJHjtUX0DE0peD==b=Si+ByTao2PgpSYKxc8egO-Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SQCVK5rd4AHppws9RWQD20HNiXTaDDkG0"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/01wsG4oK9xfw0aWtNnpIS9vGtEY
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 03:12:28 -0000

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

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