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

[Bryan Ford <[e-mail]>]

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.

B