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

Jacob Appelbaum <> Thu, 03 December 2015 03:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 686CA1B2CBB for <>; Wed, 2 Dec 2015 19:56:31 -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 HR_L-i-JK7kK for <>; Wed, 2 Dec 2015 19:56:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC44B1B2EEC for <>; Wed, 2 Dec 2015 19:56:21 -0800 (PST)
Received: by iofh3 with SMTP id h3so68735609iof.3 for <>; Wed, 02 Dec 2015 19:56:21 -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; bh=u7/rcVpWTRrBILiO3wbfzi75MxLyi5Sv+CMm96J4PJw=; b=wuVZZS4+BPn2xnoMkJrn0TjlzWZ0oR3dxAGDXaDBi+jU38AWVNhNWWQvydpkuBlOYz 8A9oxXjI0ObhXjnA63q88hGbqUow7fiv04a0W3qdsGwc/1GOAhHWtF8WBMLFbz3v7A9j DcKytZloM1UKFHecRFW9tnxQxBbbLd8WF9SOteHV7J8xnKKi2lzLz9orVFHdrC89Blc3 roLzEpZA9+JIbSPkMB7l7Q4sMH4D94hSsLfqsa7S/CR22yHocMuHD0qgncHGL7fgnpek HwgmeGfNHOrMrUDCmt0Aw9elg+3aXkRxU0wDV5lFbBHwANdekzAlpwkap+1SAqZkkUGt Twiw==
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; bh=u7/rcVpWTRrBILiO3wbfzi75MxLyi5Sv+CMm96J4PJw=; b=VaBL/WaP/mubfVyZe5pIyRJVHRZkb4SKKgUk91792VNPxHy7cE/UVzPnoNKtwEh5HW HgM01oDMOb+v8wznl7qRmDAjTuAexq8Nya+RWXXeCnHuaDrbHfN64HJOZ9a45YUuRLsP C0dMZtZYk0NaS9uBLHfnzujJqntLUivTRICcYc8U9U6LCeHCF2VgQTshdo8aBKFOnqh5 a0Zz4LcX526KcF4sz69kB2iv6qjsAvE2H4TNThwKQCa3+bSNSzK6DxR3UsHeWk4w+iQr GQx5DwD3WcAJprlv2InO2AOMH0z3QS/OCGeRQfPuk6CebAi/qmfUn4O8zVePxdkB+J7C fS5w==
X-Gm-Message-State: ALoCoQny1jycXphxh30Ot/DOaM0OD4DDqxOL1TtxFHSY4s0y0i1Gz+16CCsJqlqPkC5S8F/MWgSA
MIME-Version: 1.0
X-Received: by with SMTP id g79mr6782192ioi.81.1449114981137; Wed, 02 Dec 2015 19:56:21 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 19:56:20 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 03 Dec 2015 03:56:20 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Eric Mill <>
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:56:31 -0000

On 12/3/15, Eric Mill <> wrote:
> On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum <>
> wrote:
>> On 12/2/15, Salz, Rich <> wrote:
>> >> it seems blindingly obvious to me that we want it
>> >
>> > Few things, particularly in the security arena, are blindingly obvious.
>> If
>> > it actually provides no true protection, then it's just as bad as the
>> > security theater in US airports.
>> It provides protection. Specifically it provides confidentially.
>> It doesn't solve the fact that the DNS is a privacy violating
>> nightmare. It doesn't change the fact that the NSA breaks the rules.
> And what Don and Rich's analysis is trying to isolate is how much real
> protection you get from that level of confidentiality, so that a decision
> that weighs all available factors can be made, including the complexity
> cost.

I'm sorry but that analysis is just not a serious and rigorous analysis.

> It's not just a collective action problem because DNS isn't encrypted too.

The conclusion summary is that because there are many problems, we
won't address our part of the problems. The conclusion is that SNI
privacy isn't worth it because those who live in liberal democracies
with poor traffic analysis, well they just don't matter much. Which
is... just... well, as I said above, I just don't take this seriously.

> Their analysis also looks at what you get when both are encrypted. And
> regardless of DNS being encrypted, rainbow-table style reverse lookups of
> IP to DNS name are always possible. That doesn't mean encrypted SNI isn't
> worth it -- it clearly provides a security attribute (confidentiality) to
> an important piece of information.

You're now suggesting an attacker that computes rainbow-tables to
arrive a possibility which in itself sounds like a massive improvement
over what was an absolute certainty.

> But it's not enough to drive ahead and say that some attribute outweighs
> every other consideration. For example, HSTS' persistence of memory can be
> abused as a tracking device:
> And this was known at the time the spec was finalized:
> But HSTS creates security benefits that are well worth the cost of that
> tracking potential (which can also be mitigated through preloading). There
> are a lot of browsers and communities which use and advocate for HSTS that
> might generally balk at creating tracking devices.

Yes, tracking with HSTS is a problem and there is work being done to
mitigate that tracking concern.

> I'm not advocating a strong stance on whether encrypted SNI is worth
> pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But
> it's useful to keep the debate framed in its full context, rather than
> narrowing it to a black-and-white discussion over whether a generally good
> attribute is good or not.

Sure and that full context includes RFC 7258: "Pervasive Monitoring Is
an Attack" - something that defines reasonably clearly many of the
concerns I've stated.

All the best,