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

Yoav Nir <> Wed, 02 December 2015 13:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 05E601A8AF4 for <>; Wed, 2 Dec 2015 05:38:31 -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 z4SbS56rXRqF for <>; Wed, 2 Dec 2015 05:38:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40DDE1A8AF3 for <>; Wed, 2 Dec 2015 05:38:28 -0800 (PST)
Received: by wmww144 with SMTP id w144so57222664wmw.0 for <>; Wed, 02 Dec 2015 05:38:26 -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 :content-transfer-encoding:message-id:references:to; bh=tJRoKa7TKPzPw4PJESfJnuzcHeRg1WSAnsYju8jdthA=; b=hB720mR1oTNk3VWlX5OpKnA8FcIDk/Cy0St0V51bNniiRGZYRgiTTvDGHROOLVa5yY eyA1D7udUHxF7TTVQqFeS6UTeLRs4ZdGF9M9vcK6SyC9s0q26x+CdDbUo28R0AF8qcaO QUV0C2Kan38BmYVstxxnKsvE6JQxLDm6CCGKDXD0yCWiNcnXwrcL4DNrj70yv7aaDTvq PIgYewtgugvV+eWdqHL62qaW4YnLxd7KAOvbKrOCO5DiIiQK8kmDukzvKe0R5f7xeE3R qAzY0u0x8NypM2a3J5T45eofZx4e1QNs8xxzqh05kJTSvXwzeoy+G5VLKzjOiG5btWOA 5kXA==
X-Received: by with SMTP id a189mr43761185wmh.74.1449063506842; Wed, 02 Dec 2015 05:38:26 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id n7sm3238035wmf.21.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 05:38:25 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 15:38:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Jacob Appelbaum <>
X-Mailer: Apple Mail (2.3096.5)
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 13:38:31 -0000

> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <> wrote:
>> 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?

To be clear, I don’t represent anybody. If I did, I would have to clear this mailing list message with a corporate lawyer and PR department.

I don’t think Bryan’s proposal will hurt the capabilities of a Check Point firewall, and it will make life difficult for me as a developer no more than it will make life difficult for developers of OpenSSL, NSS, SChannel, or any of a dozen other TLS implementations. I don’t know about the other IDS/IPS/Firewall devices.

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

I suspect that the Blue Coat people on this list do not represent their employer either.

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

A TLS proxy requires user consent (or at least device administrator consent) with TLS 1.2. TLS 1.3 does not change that.

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

IPsec has had a lightly-implemented TFC feature since RFC 4301. Without it a packet of IPsec is the same size as the original plaintext packet + a constant overhead rounded up to 4 bytes. So you could do as much traffic analysis on non-TFC IPsec as you could on the plaintext.