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

Martin Thomson <> Thu, 03 December 2015 03:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8E42A1B2C79 for <>; Wed, 2 Dec 2015 19:49:22 -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 Q-6rt9l3-7sj for <>; Wed, 2 Dec 2015 19:49:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5861F1B2C2E for <>; Wed, 2 Dec 2015 19:49:20 -0800 (PST)
Received: by igcph11 with SMTP id ph11so3056622igc.1 for <>; Wed, 02 Dec 2015 19:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N5z29g9oHvIPB8CAcHONZIywfk6bcohN4zNZ5Ck13gk=; b=tAU4+DWdqM47pWaTxdJcwKeMGpwxAK4fD+cuMzU7ed9Br6sf3SJBYABGbTdb2jEpau zkXv31tI1ZQBYP+5e/1X7+qQU4rAmGywz5ujBtcuHUZ7X5FxRC0pVtxQrhNQxFg8Iu/Q 1/PnGnmElrxDTxq5kegOt6TLJHxtzZOf4H6vd21Vv2GlULn8qh+Lqutzn50m9STIFGDm 1ry9zSdjA/ZZcZuM2YWfLm/vmoweokHChMQva9SCmczm+82EiymZ6922X5xyDvGBD24i VAVMUMksqQ8/eCScLeJrNVs9OFm92KoT2S9WWHqEHuLmV2ApALv9DG+MdryYGsSACjcd YDyg==
MIME-Version: 1.0
X-Received: by with SMTP id o6mr37921937igh.94.1449114559784; Wed, 02 Dec 2015 19:49:19 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 19:49:19 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 03 Dec 2015 14:49:19 +1100
Message-ID: <>
From: Martin Thomson <>
To: Jacob Appelbaum <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
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: Thu, 03 Dec 2015 03:49:22 -0000

There are a lot of inaccuracies in that presentation, so I wouldn't
pin too much on it.

In any case, before we all get too excited about this, there are some
solutions, I've seen a write-up of one of them, but it was a little
hard to follow first time around.  Some of the things that are
described as impossible aren't that hard to fix.  On the flip site, it
doesn't provide a fully general solution.

Expect to see something very soon.  Until then, I don't think that an
in-depth on what isn't even at a straw-man level of detail is that
helpful.  We need details before we can say whether the cost-benefit
makes sense.

On 3 December 2015 at 14:38, Jacob Appelbaum <> wrote:
> On 12/2/15, Dave Garrett <> wrote:
>> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>>> Encrypted SNI doesn't give you the kind of protection you think that it
>>> does.  We (me and a colleague) did a pretty thorough analysis that showed
>>> this.  It was not a conclusion we expected, or wanted, to reach.   It was
>>> presented at the TLS Interim before the IETF in Toronto.  Slides should be
>>> online.  (For example, the adversary will know the IP address or might not
>>> care about false positives, etc.)
>> URL from Rich's previous email citing this:
> I've read these slides. I'm... at a bit of a loss. The entire slide
> deck seems so flippant as to be not worth addressing. It just doesn't
> even pass the giggle test.
> Though upon reading it, I am struck by two core points:
> One is that big companies will be pressured by governments.
> Ironically, Akamai isn't one of those as they're willingly in bed with
> governments around the world. But I guess as the slides say, the
> author isn't speaking on behalf of Akamai. That said - good, I want
> governments to have to go to a company rather than to the user - the
> company may have a legal team, the user may have hidden or otherwise
> protected themselves. Hopefully the company is in a position to do
> nothing or will take action to protect the user's basic liberties.
> The second is a constant security nihilism. Yeah, a lot of stuff is
> broken - so lets acknowledge it bit by bit and then fix it all.
> I would encourage everyone to read the slides as the conclusion in the
> presentation simply do not follow. If I had been in the audience when
> they were presented, I would have been at the microphone objecting.
> The idea that this convinced anyone is baffling.
> It is clear that privacy concerns exist in many many different
> protocols and that many protocols need to be fixed. Many people point
> at other protocols as a way to punt on the issue for their own
> protocol. The cycle continues and the privacy violations continue
> without end.
>> Please don't brush this argument off in favor of the "obvious" answer that
>> encrypted SNI is helpful. The sad truth is that it's a lot of effort with a
>> lot of risk for virtually no gain. I was quite in favor of encrypted SNI
>> before reading it, and I had to concede the point after. If we can come up
>> with a way to do it easily, ok, but it's not an avenue worth spending too
>> much time on.
> The idea of splitting the world, as the slides do, into three basic
> camps (liberal democracy with good traffic analysis, liberal democracy
> with bad traffic analysis and horrible dangerous places) is simply not
> serious. The idea that our liberal democracies do perfect traffic
> analysis and so we should ensure *everyone* including *non-NSA*
> attackers can do it for *free* is just bizarre to me. It is incorrect
> as a conclusion to do nothing because some people somewhere *may* be
> good at traffic analysis. The logic of the slides suggest that raising
> the cost from a kid-in-a-cafe to NSA is proof that we shouldn't
> bother. Again, the security nihilism monster appears. We should reject
> this nihilism and fix the problem.
> Encrypted SNI makes sense as it makes traffic analysis harder.
> Encrypting DNS queries makes sense too. Composing it with other
> systems may or may not make sense. Even when TLS is composed with a
> tool to do traffic analysis resistance, the exit node of the
> TA-resistance network can still do selective attacks based on SNI. In
> that case the DNS is likely to be resolved at a different exit point.
> Thus if we want to punt again and say, hey, traffic analysis
> resistance is better left to Tor or something else, please consider
> that plaintext selectors make Tor's job harder.
> These changes make it more expensive and in some cases, it will stop
> attackers who would otherwise be able to make an attack happen
> undetected. It requires an attacker to spend more money on CPU, memory
> and on other resources to do correlation across multiple collection
> points.
> Kicking the can down the road doesn't even begin to summarize why
> leaving SNI unencrypted is incorrect. Metadata is a serious problem
> and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF
> TLS list), even in liberal democracies, helps to solve the problems we
> face from mass surveillance.
> All the best,
> Jacob
> _______________________________________________
> TLS mailing list