Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Jacob Appelbaum <> Wed, 02 December 2015 12:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DAB01A89F6 for <>; Wed, 2 Dec 2015 04:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MGzDrggHPyiO for <>; Wed, 2 Dec 2015 04:59:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F0BD1A89FA for <>; Wed, 2 Dec 2015 04:59:13 -0800 (PST)
Received: by igcmv3 with SMTP id mv3so116865258igc.0 for <>; Wed, 02 Dec 2015 04:59: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=6X9/9pOqrZ4umLOLQtHP/+p5URQETdzn5tNiokJfmAU=; b=GCXP0S+c5INQScclnLr6K7O5yd0aVDWuGcRCRsC6EakTn4h6E57abuQDiT0ecWtWW3 SGEcgFmeAkA3zZL8jX8Xis87cgb/ljUTtmOeUrA1mNFkdKBF6z+Vl0VWEz4xzwzlBYpd qlzxOV7vahxqmlkL/a2p0lmOYeYfy18SSM8ahVQS66Nxi8fIBZtVghs60/W8lGuvq7iR U/i+uSv2bwbo+LOEFVJHM7dmHPuyiDfz05pLXtS2UQfkIU25h/AdYdUHDyKduTEmwM56 YP9CSb1qWzVV2tp1z+wxnhStQ5UuTlh2gW5pXsc4uqTIAyllSe1gI85m+qEjGnofO6Qf x9yA==
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=6X9/9pOqrZ4umLOLQtHP/+p5URQETdzn5tNiokJfmAU=; b=mrokmttPLLWE9pEjf86pSt6bW3V1NLyulKl7zn/UtVyvmYoryGqV3EZF7fPg3n7/tl X51l8B/rCaw0V6BMxFhmqxD+4grpXYrRtID9NX2AqREs4fJW1SDnQLG6CMaD8lCm9T0/ /j8zskBJFboQl8YLs19qPLpOdvVlcbceCVM8nU6bVKbzA7gkKuAVdNOSecuDdbtUcd90 fR/PaBwBh1azqVLS7VPNN8Yw5/dEI5w32zxkmGdJG9JTL6XDLvmIED23I0ux8ey1twng ow/tOSHRLJM2PsZKOcb4BHmO78Fq2PKaTNtcsNJff2rvIimZqudovz0/pLtWS7nKgQPg HDZQ==
X-Gm-Message-State: ALoCoQlabbl2m6cmro2v3oaEEZX29oowxohbMALaAolQjfew6zdaY1K/hd+9IcYNuAsKb4DvGnfg
MIME-Version: 1.0
X-Received: by with SMTP id sa12mr1062843igb.82.1449061152926; Wed, 02 Dec 2015 04:59:12 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 04:59:12 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 02 Dec 2015 12:59:12 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Yoav Nir <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] 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 12:59:16 -0000

On 12/2/15, Yoav Nir <> wrote:
>> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum <> wrote:
>> On 12/1/15, Yoav Nir <> wrote:
>>>> Which would those be? And what is the definition of capital-intensive
>>>> for those watching on the sidelines?
>>> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on
>>> protocols to make sure that the stuff going over TCP port 443 is really
>>> HTTPS rather than an attempt at tunneling.  There are some attacks such
>>> the
>>> the code that protects against them needs to follow TLS record sizes.
>>> For
>>> the most part these are not-so-interesting attacks, causing certain
>>> versions
>>> of certain browsers to hang, and they are expensive for the firewall to
>>> protect against, so for the most part these protections are turned off.
>>> But
>>> it’s not everywhere.
>> Could you be more specific? Which devices are we saying will break? Do
>> you have model numbers? Are those vendors on this list? Do they agree
>> that this will break and do we agree that they are a relevant
>> stakeholder who has a user's security in mind?
> I am no expert on middleboxes. I know a little about those that my employer
> (Check Point) makes. I only know a little, because I’m on the VPN side of
> things, not the IDS/IPS/next generation firewall side.

I don't think we should worry about breaking poor little Check Point's
traffic analysis devices. Allow me to shift the overton window: their
device is a problem and we should treat it as a problem on the
network. TLS should mitigate as many of the advantages that they use
to harm end users. We should make those devices use as much RAM and as
much disk space and as much CPU time as possible. In the words of a
Google engineer who discovered the NSA had been doing traffic analysis
on his backbone...

> These are corporate
> firewalls. When it comes to filtering HTTPS connections, firewalls have
> three ways to classify the connection:
>  1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses.
>  2. #1, and additionally follow the stream looking for certain patterns.
>  3. Full “TLS proxy”.
> Each of these is “heavier” in amount of resources that it consumes and in
> the amount of breakage that it might introduce than the one before it, so
> you only use a higher-numbered way if the lower-numbered way does not give
> you the results you need. Specifically for #2 which is the one we’re
> concerned about, there are very few attacks that can be detected by #2 that
> cannot be detected by #1. I asked someone who does work on these
> “protections” as we call them, and she told me that only two or three
> protections require following the stream that do not require proxying, and
> those were turned off in the default and recommended profiles. So at least
> with a Check Point firewall, mostly you would not get breakage if record
> lengths were encrypted, but someone making a client or a server cannot
> assume that all paths will be free from such inspection. Also, there are
> many firewall vendors and one is installed in most corporate environments.

That sounds like you're saying that the vendor you represent won't
have issues and that it isn't a problem. Unless I misunderstand,
you're claiming a concern and you've just cleared up that concern. So
we can move on with Bryan's proposal?

> So at least one vendor is listening in on this list, and I have a good hunch
> that at least Cisco, Blue Coat and several others are on this list as well.

I'd love for Blue Coat to step up and talk about how this is similarly
not a problem or how it is a problem for their illegal surveillance
business in Syria, where they've been caught selling surveillance and
censorship gear. I suspect they won't say much but we can hope, right?

> Whether they are relevant stakeholders or not is to me the same question as
> whether the network administrator in a corporate environment is a relevant
> stakeholder. We just make the middlebox that they deploy.

That is a kind of goal post shifting but seeminly weirdly not
relevant, if I understand. If it won't trouble the middle box, it
doesn't sound like the network administrator will have troubles.

It will however reduce off-path reassembly to technique #1 from above
and #2 will be partially eliminated and #3 isn't an option for that
attacker anyway.

We are working on solutions to #1, TLS 1.3 should reduce and if
possible, eliminate #2, and #3 is something that should require
consent of the user in question. Without consent, TLS 1.3 should hard
fail closed as a security measure.

>> For example, do we really care what sandvine or xkeyscore or narus or
>> similar vendors think? I think the answer is no. They're still going
>> to do extremely powerful traffic analysis and the more information TLS
>> leaks, the more they will use it to degrade the security of TLS for
>> all users. It may be that they will be full, on path, attackers and
>> yes, in some cases, they can do different more powerful attacks.
>> Again, we should treat that as a negative thing and make it as hard as
>> is possible.
>>> If enough middleboxes block TLS 1.3, the browsers will implement a
>>> downgrade
>>> dance. If they do that, attackers will be able to exploit the downgrade
>>> dance. I don’t think the net effect is better security. We’d be far
>>> better
>>> off writing a separate document on how to use the padding feature that
>>> is
>>> already in 1.3 to mitigate traffic analysis without actually flooding
>>> your
>>> Internet connection. Splitting records and padding a few can be more
>>> effective than masking the length bits.
>> Censors are going to perform surveillance and then censor; TLS 1.3
>> should treat surveillance as a security issue and censorship as an
>> attack. It may be that we can't stop certain kinds of on path attacks
>> but man on the side seems nearly entirely do-able. I mean aside from
>> the TCP reset issues do to layer violation concerns. At least we'll
>> have DTLS, which won't suffer from such a trivial denial of service...
>> right?
> Or just use IPsec (I did say I’m no that side of the building…)

How well will IPsec deal with such an adversary? I think it is
instructive at all the ways that a protocol won't compose cleanly with
something like Tor, as well as how many distingusihers exist for
technique #2 above. It is very frustrating because yes, it would be
nice if we could just use IPsec. That is however nearly a total lost
cause with regard to surveillance and censorship issues. I once talked
to a Narus vendor who made some amazing claims about traffic analysis
on IPsec - I'll try to dig up some documents.

All the best,