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

Eric Rescorla <> Wed, 02 December 2015 14:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 620BE1A90CC for <>; Wed, 2 Dec 2015 06:37:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EyZcbHzpCK3f for <>; Wed, 2 Dec 2015 06:37:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4DDF1A909D for <>; Wed, 2 Dec 2015 06:37:14 -0800 (PST)
Received: by ykfs79 with SMTP id s79so48708564ykf.1 for <>; Wed, 02 Dec 2015 06:37:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1QzIU8hXxv908FJyQxWcVZjTcrR77qJrTDBY4XnivsU=; b=1RGcGOLngn7F8gBXtbGr4eAJJ9C8Ut80zWcM2kT9se87sxJHI66K0Pg3OP9CMlZUtq Y9C1Ueh8yJF7R6ai7bjxKsI3hX8JvIoSuKEn7tBxKxR4i6EPwWoIuM2LyXmsNB09pfuE mv1XDyutcX3Wt9K2vYhJC8Hy7CYcmpv6jD+Cv6A56CKcGDwA0cfMdcsPfMe3k0oyZsml Z6CXpiW+VesQ+4WYYYn3W4lCCl9A9Cj0SNfmT2XJBfJCVUZplFF4vPePoZbu9TgU00Vr dAhrVyEScmUei6EZZBGT6Gzh7t81RTodesqpb7l2WR/067eBnUHuct6FAYTI4/D3ifDC bErw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1QzIU8hXxv908FJyQxWcVZjTcrR77qJrTDBY4XnivsU=; b=DRWrETEBOvskdS8vlSXGyA4s8CzSw4MLtg2gHKNVxPQm8vzmTSpSrU538Yz+hnBAtl jKMrxK6Bljz9OwTQYSX2GZU3zLN96Drv9hvWeF/d3Fy96Pi4dlV0ROM3JRG+bJKv+31p ANNeSSKA+rNsfH1n7A/b/p4gFuEK5LLn7k2rHoLFPhq0tgKoLMStBprzDtZtcgQ54kth G0LppZx4luSdcnNwBBOxSX3nn82rqsfGloyjCEF/9DX0T/OtavcrvbRhUWpX9iXjDW/j 6KGC7j0YOk9eRq9n97btNHBajlU0bm5toMNsE85Qmc0GyMHbuOlXuDcGAW4vTIvEs9ll 3+eA==
X-Gm-Message-State: ALoCoQngrEoYAxn99c2Qbu90w2bZpx9hfw4D5hg1gO4nM0HK8v4vWgapcHYZgfr+nsMGGoIgTUKB
X-Received: by with SMTP id v10mr2706115ywe.231.1449067034093; Wed, 02 Dec 2015 06:37:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Dec 2015 06:36:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Wed, 02 Dec 2015 06:36:34 -0800
Message-ID: <>
To: Bryan Ford <>
Content-Type: multipart/alternative; boundary="94eb2c0889dcd2d84c0525eb351c"
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 14:37:16 -0000

On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <> wrote:

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

It's not really clear to me what the anti-traffic-analysis benefit of your
is over and above just padding everything to a fixed size. That's certainly
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.

The primary security improvement of your proposal seems to be that an
active attacker can't generate a packet header that will put the TLS
implementation in a deadlock state where it's waiting for more data that
will never come. This seems of modest value in TLS [0] given that the
can cause the connection to be torn down by modifying any packet.
I agree, that this is not exactly the same as leaving the connection
but it still effectively breaks the connection. In addition, I'm not an
expert on TCP internals, but can't you also cause a similar deadlock by
removing a TCP segment sent to the receiver and then ACKing it to the
sender so that there is a gap in the TCP stream?


[0] This issue doesn't apply to DTLS because the stack will just move onto
the next UDP datagram.