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

Jacob Appelbaum <> Wed, 02 December 2015 15:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 58F6A1A8ACD for <>; Wed, 2 Dec 2015 07:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id spE5zYbvL9Qa for <>; Wed, 2 Dec 2015 07:34:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 773B31A8AB3 for <>; Wed, 2 Dec 2015 07:34:13 -0800 (PST)
Received: by iofh3 with SMTP id h3so49278541iof.3 for <>; Wed, 02 Dec 2015 07:34:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EwtOeFt9Pd4V/DcayHXpEq9VbX6FRp0jXfDDXHX0dC4=; b=wYPm3JCIK6lVyCd7DjCqJC5rCAsm9VxvQ6rnkvlZcOuJBu9ik+faOWjUASBv2og0mW 6C4Jayc5Mb9Mg0Pm4m5XXbdXyZwjvzUU+7zDZfGRtmayy4hzVMhneL6pEqjcr/OaGuTn VcCX16A87V53CtcttRuV2pX9x6JtxQoo4i/XAJV0YWJ1VmvChjGq6ciP09G08qL5Ioqt aikT+JYeRLTg913S7F0KhvpweJcc1qMeut4zusr96YtU2A8zCPvGT9bTVAb8WEcfVqB9 W2w/BVN1nV/nba+nOW4cVdGqLm8v/VR8cWzNTrgU/cRlDMm0lEEwMakv4dzJSRJjDVy1 pPaw==
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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EwtOeFt9Pd4V/DcayHXpEq9VbX6FRp0jXfDDXHX0dC4=; b=HwBaIVzDKXm7tV+3FEV+goGqADot+AwDlxGumtRGUEMSoSl8zJM6+Ap63cBi7mQDrW 7/bA0o5eF9uu17vU2Z5xQHDoA4CIsBLmB2DsZlDOAv7LHEP87LqRiFdITmMkL48xpXeY QD6cbgpDz6X8zj5cnWyLJHpkKwJgBxpcWM0o5m9El/FhzxcwyMl047yH/giQARh7UHjJ FNNjk8pRaHb9oUOvdCPypI+xmD+KcqNZiCM+yN3CrKSX0LtSMR3FN/a1sYdd5AK0vHUV sefmHQQWimi11cN7Wn+Rnv7SUw4BvSciaN0efVJasdH8jjg5u8ttdhW6GnRO22S0ag+2 0/xw==
X-Gm-Message-State: ALoCoQlXxCBQgQs4CMKmH5TAJ0smhJWSIoftNijJpdt8c1wm6W/mVKX2TDHNnGWS33QxJFhm2eXM
MIME-Version: 1.0
X-Received: by with SMTP id l19mr3692461iod.138.1449070452857; Wed, 02 Dec 2015 07:34:12 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 07:34:12 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 02 Dec 2015 15:34:12 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 15:34:15 -0000

On 12/2/15, Eric Rescorla <> wrote:
> 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
> 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.

> 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
> attacker
> 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
> deadlocked
> 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?

Yes, any TLS connection may be broken by TCP's total lack of
confidentiality, integrity or authenticity. It seems that normally
this happens at setup by IP:port blocking or during later transmission
of a selector/distinguisher that triggers an attack (TCP RST or
others). There is good work in this area by David Stainton with his
Honeybadger project - he actually classified and implemented most of
these TCP attacks to help detect QUANTUMINSERT attacks in the wild:

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

An off-path attacker can't do much with DTLS, if designed correctly.
Especially if they only see some packets - they'd only get the UDP
headers and then the rest should be uniformly distributed random data,
no? An attacker could thus only interfere during setup - which if
they're on path - we can't stop and expect; the PKI should (ha!) help
with this issue. After that point, especially with devices that move
or are otherwise multi-homed, would be able to spray encrypted packets
out to the network with little other than the UDP headers for an
attacker to use.

Bryan's proposal makes things strictly better with regard to a network
attacker - especially a partial view or off-path attacker who can only
inject packets or who require a selector to trigger an attack.
Effectively, an attacker will be forced to shut down the connection at
setup time or to use the layer separation issues with TCP at any
point. The key difference is that they will have the same information
as they did at setup time, which again seems as a strict improvement
over the current status quo.

All the best,