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

Bryan Ford <> Wed, 02 December 2015 09:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85D701B34D8 for <>; Wed, 2 Dec 2015 01:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FL8haCVbrVId for <>; Wed, 2 Dec 2015 01:07:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 896D41B34AE for <>; Wed, 2 Dec 2015 01:07:36 -0800 (PST)
Received: by wmww144 with SMTP id w144so47584627wmw.0 for <>; Wed, 02 Dec 2015 01:07:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/OgrHZ8qmbG2HT6GQyP3A5orIfwl2Yz5OFKoVvjEXIo=; b=mLTzRt5V3CoH6UGEFLDGZ5VKp+eOKzNfNFEs8vWOcbitTvWJ6aqXGDTycSkHUhVEsd H4QLB6uki0G8dLtv8T7Lodrv9RpzcAmdOoZ0LB29w2VB1YGVkfMgaZcIcY19fRbA3hk9 ggC1OVjrCZ/CEOSlbFO3+hWq2gjJb6+DCQBtD5O5XgdzZ8xp5CTClzo5dh8A1J5dA8w8 /Pp08fy7jml8PbMcE64F6SFtY8EYUgZccldmOa7OOprJNv7ebliQEjpDYfLP6GoEkTff j612F+NMP83rn9hCNYLMP/oPfe+dpNVHp5Fjsr+HAU8CXEhiwwPVQgiCuLbnkfV4jp8Z uQlw==
X-Received: by with SMTP id k3mr3102348wje.19.1449047255175; Wed, 02 Dec 2015 01:07:35 -0800 (PST)
Received: from ( []) by with ESMTPSA id bk2sm1834975wjc.3.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 01:07:34 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_815073C7-14DD-4BA6-89E5-382E9BCA667A"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Bryan Ford <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 10:07:33 +0100
Message-Id: <>
References: <> <> <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Dec 2015 09:07:39 -0000

On 02 Dec 2015, at 06:02, Martin Thomson <> wrote:
> On 1 December 2015 at 08:22, Bryan A Ford <> 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.