Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Jacob Appelbaum <[e-mail]>]

On 12/3/15, Watson Ladd <[e-mail]> wrote:
> On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum <[e-mail]>
> wrote:
>> On 12/2/15, Eric Rescorla <[e-mail]> wrote:
>>> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum <[e-mail]>
>>> wrote:
>>>
>>>> On 12/2/15, Eric Rescorla <[e-mail]> wrote:
>>>> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <[e-mail]>
>>>> wrote:
>>>> >
>>>> >> On 02 Dec 2015, at 06:02, Martin Thomson <[e-mail]>
>>>> >> wrote:
>>>> >> > On 1 December 2015 at 08:22, Bryan A Ford <[e-mail]>
>>>> >> > wrote:
>>>> >> >> The 2-byte length field in each record's header no longer
>>>> >> >> indicates
>>>> >> >> the length of the *current* record but instead indicates the
>>>> >> >> length
>>>> of
>>>> >> >> the *next* record.
>>>> >> >
>>>> >> > Ensuring that you know the length of the *next* record is
>>>> >> > difficult
>>>> >> > and could dramatically degrade latency, or adding extra bogus
>>>> >> > padding
>>>> >> > or extra bogus records.  For instance, I can always send in bursts
>>>> >> > of
>>>> >> > two packets, a one octet packet that promises the remainder of the
>>>> >> > burst and one that promises a single octet packet.  At that point,
>>>> >> > I
>>>> >> > get to do what I've always done and you have gained little other
>>>> >> > than
>>>> >> > an increase in packet size of around 19 octets (best case).
>>>> >>
>>>> >> That type of inefficiency is extremely easy to avoid; please read
>>>> >> the
>>>> >> rest
>>>> >> of my proposal where I discussed exactly that at length.  Yes, a
>>>> >> particularly stupid implementation could send everything in bursts
>>>> >> of
>>>> two
>>>> >> packets, but it’s ridiculously easy for a slightly smarter
>>>> implementation
>>>> >> to avoid doing that.  And what you’ve gained is complete encryption
>>>> >> and
>>>> >> integrity-checking of the whole TLS record before any part is
>>>> >> interpreted,
>>>> >> which seems like a nontrivial security improvement.
>>>> >
>>>> >
>>>> > It's not really clear to me what the anti-traffic-analysis benefit of
>>>> your
>>>> > proposal
>>>> > is over and above just padding everything to a fixed size. That's
>>>> certainly
>>>> > far
>>>> > easier for the implementation to do, especially in typical stacks
>>>> > where
>>>> the
>>>> > application just calls SSL_Write (or whatever) and so there's no
>>>> > obvious
>>>> > API point to provide the "next length", so as a practical matter the
>>>> stack
>>>> > will very often if not always be in "last block" mode.
>>>> >
>>>>
>>>> I think that it eliminates all static distinguisher in the protocol
>>>> for all data covered by the encryption. That is a fantastically
>>>> wonderful benefit.
>>>
>>>
>>> Wouldn't that benefit be equally achieved by simply padding all records
>>> to a fixed length? You could do this with no protocol change and, as I
>>> said, it's far easier for the implementation.
>>>
>>
>> Padding is potentially useful but has two issues that come to mind
>> which are both non-issues in most cases. The first is the economic
>> cost for extra bytes and the second is the security of the padding
>> scheme.
>>
>> Padding strategies are a complement super encryption but probably not
>> a replacement. Padding protects against one set of attackers (bean
>> counters) and super encryption provides confidentiality against
>> another set of attackers (GPA/APA).
>
> But as several people have noted, encrypting record lengths doesn't
> actually protect the lengths of the records
> as well as you think it does.

I think it protects the length data exactly as much as it does. :-)

It doesn't solve the problem that for a given TCP flow, we'll have a
byte counter, of course. That is also why I'm quite interested in DTLS
with super encryption. Especially with users roaming across networks,
I'm hopeful that we'll blind partial view attackers even more than
ever.

> Timing packets is not some exotic and
> unavailable technology. I don't understand what
> attacks padding and introduction of dummy packets doesn't defend
> against that encryption of record lengths does.

We should also ensure that we have padding and dummy packets, of course.

Still I don't see that we'll turn TLS into ATM nor do I believe that
we understand an optimal padding strategy. I think you are correct
that an attacker with a clock and a bean counter is a valid problem. I
also think that the more state we force an attacker to hold, the more
expensive it becomes to perform correlated traffic analysis across
global networks.

Super encryption of records also means that accidents at one layer may
not be as catastrophic at another layer.

All the best,
Jacob