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

Bryan A Ford <> Thu, 03 December 2015 09:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C5901A877B for <>; Thu, 3 Dec 2015 01:29:15 -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 A-0fzCol7nYb for <>; Thu, 3 Dec 2015 01:29:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71DA81A8733 for <>; Thu, 3 Dec 2015 01:29:13 -0800 (PST)
Received: by wmec201 with SMTP id c201so13644831wme.1 for <>; Thu, 03 Dec 2015 01:29:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=td9yEVkC4ZD5uNOxXLG3iT44md2/5BQqbsicByFcoms=; b=rdlglDM5iSYPweIP9gurqWZ8Ylese7lYTfD3gMvRo41ryUXvjgzofU7tpPNf66sr47 Fc3rt5a7biIZrRtyfloy1/mb6WZ7Uulat6sn3dIhTvz+5SLtrlE2eSwnf9Y2k4K5rAWZ VzrkW5qYgwRFjkI+dPH1GuQJdUE6XYqRy0q2wXjk13uAPlaySCjGo0euQGMn2zqJ7Bk8 +Yql2SoEYM5yqLlavqgwZPcs/OL1B/5G5CN+NqYhLraT9pxRA++eKvc7FKmk4NHonPWs 6kzr8qjjg0abmgp1LQ8pYXrfQMCTpRvCxUmR0XO/yBVkf4yXEDoMHbQXhcxl1Meg/ICD ETBg==
X-Received: by with SMTP id g128mr51305691wmf.95.1449134952062; Thu, 03 Dec 2015 01:29:12 -0800 (PST)
Received: from ( []) by with ESMTPSA id uq3sm6633706wjc.10.2015. for <> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 01:29:10 -0800 (PST)
References: <> <> <> <>
From: Bryan A Ford <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 03 Dec 2015 10:29:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090709040007080005060005"
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: Thu, 03 Dec 2015 09:29:15 -0000

On 12/2/15 9:13 PM, 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:
> 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.

I find it darkly amusing that this argument against the usefulness of
encrypted SNI, supported in substantial part by an argument that "1st
world eavesdroppers do TA really well", is being brought up in the
context of a discussion of my proposal to make traffic analysis harder
by encrypting TLS record headers (in combination with other useful
techniques such as padding).

By all means, let's not encrypt SNI because traffic analysis is easy,
and let's not make traffic analysis harder because SNI is unencrypted
anyway! ... or something like that. :/

I completely agree with Jake's arguments against security nihilism.  The
fact that we can't completely and perfectly solve the whole problem all
at once should not prevent us from working on little pieces of the
problem bit by bit and making life incrementally harder for at least
some of the wide diversity of adversaries out there.


> Dave
> _______________________________________________
> TLS mailing list