Re: [TLS] Reducing record expansion overhead allowance

> 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