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

Jacob Appelbaum <> Thu, 03 December 2015 23:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 993401AC3E1 for <>; Thu, 3 Dec 2015 15:46:43 -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 b0GttmG7Tj30 for <>; Thu, 3 Dec 2015 15:46:42 -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 CBB1C1ACC88 for <>; Thu, 3 Dec 2015 15:46:41 -0800 (PST)
Received: by igcto18 with SMTP id to18so24312411igc.0 for <>; Thu, 03 Dec 2015 15:46:41 -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=o69xB5W2BbxtGMkpZRfFmQWkudJ5xwnjdJjd70gW95o=; b=RO9cZoo0qqX/q4dPpErhnpm1XMEhnYytES1JgM6Aw8mwcFpFon/0fCkjmdtOTif3af TdeKyw6pn5mGgR5LA09ZWPERbNHsCqXL/PlrWpXUF7NBGeL6hblcqx2xFS706pRwgNLC qc5H5qhSfw5WsRCu56soqtgyjRf+feRZqFEoc7BzP5sNn7xZpFsMg7xxjIA+aNrIYBq0 ceu9zOzWcqvkoM5SfmlayRFVcTJeLEPtk99vsfREX5zB5x2W0fyZWhgSjvkvtRrYDqLr 3epEgV9SEkdRpfhdc9+b8P9Jjk0Q+lWeq0fvF02EdUkwFCZS5GDlHjJN5aKN6akzrunJ SZlQ==
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=o69xB5W2BbxtGMkpZRfFmQWkudJ5xwnjdJjd70gW95o=; b=OnPlW3OYhOtEipCh2OsVxP5CN9ZqbbzE1LTxbKTpYpnHWh5z1JYIffEESL8YAtz9oC IkWb9Z+KASLi/0ZdJiUt48irtduiB16ovkEzfcPMQ0HHyB7vJ7nZWL340r6Rb0glGchp iMuKQfI+Bseb+VW0vupZL0S4w6sUajbWUgG37zzBfXPE/DO21JAb6w8cZ5njZdPUPaaR ex2pTkvsIiVt3A2KB596EcGv+GgApOE5N44K40fR4MVymMYKlD7f8DeKfUmdrNJeG7mN YHFUxJgVKLOzcFhnE7wLiBR9a7i/XJDaVF59PWvvf6qTHebOLliOhHmqlfHdL6dwnWAq mmww==
X-Gm-Message-State: ALoCoQkgT2mlUsMU6SKl378bmOy5Ec7L0GBh1bCC0k+KjOhzO3jmcgEtz4u4ipplV7kVOM6iMB0rJE+pKkJ7jEEonKy3G/IyaQ==
MIME-Version: 1.0
X-Received: by with SMTP id t13mr1301582ign.89.1449186401284; Thu, 03 Dec 2015 15:46:41 -0800 (PST)
Received: by with HTTP; Thu, 3 Dec 2015 15:46:40 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Thu, 03 Dec 2015 23:46:40 +0000
Message-ID: <>
From: Jacob Appelbaum <>
Content-Type: text/plain; charset="UTF-8"
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 23:46:43 -0000

On 12/3/15, Martin Rex <> wrote:
> Jacob Appelbaum wrote:
>>>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less
>>>> secure
>>> That is a myth.
>> Are you asserting that TLS 1.3 will be less secure or equally secure
>> here?
> Even TLSv1.0 is sufficiently secure already, so that there
> are plenty of other attack surfaces *MUCH* easier to attack.
>    Arguing about whether a key should be 112 bits or 128 bits long is
>    rather like pounding a huge stake into the ground and hoping the
>    attacker runs right into it. You can argue whether the stake should
>    be a mile or a mile-and-a-half high, but the attacker is simply going
>    to walk around the stake.

I look forward to using that poor saps TLS 1.0 services - where TLS
isn't the weakest link!

> If you design anything around TLS where the "secrecy" of the servername
> is important, then you are acting extremely irresponsible.  There are so
> many ways and places where the servername WILL be leaked, (URLs, bookmarks,
> HTTP-Header-Fields,  HTTP-Referer headers, etc.) that bottom line,
> encrypting
> SNI amounts to crazy and pointless idea.

Huh - Could you please enumerate all of the places that TLS leaks a
hostname requested by a client? Each one of them is a problem and we
should correct it. TCP/IP and DNS are out of scope, though obviously

> Using sha1(servername) instead of servername is (a) not confidential
> and (b) backwards-incompatible with the existing protocol&usage and
> the installed base.

That was not a serious suggestion. If you think that I seriously
suggested hashing the server name, I'm sorry. Please re-read my email
and understand that I was suggesting that we can change the value of a
field easily to make the attack more expensive. To make it worth
doing, we want a better scheme than a straight hash of a name, of

> No matter how many hoops you jump, encrypting
> SNI will never become anything close to a TOR hidden service.
> And for the vast majority of servers, there is going to be such
> a small number of virtual services, that distinguishing them will
> always be trivial by their traffic patterns.  There is nothing that
> TLS could do about app-determined traffic patterns of unrelated
> TLS sessions.

We probably agree here - there is a case where you want to compose
with Tor. However there is a different issue which is that by leaving
the client requested name in the clear, an attacker, even against a
Tor exit node, can denial of service a specific client with nothing
more than a word list. This is no different from HTTP without TLS for
tearing a connection down; it becomes different with TLS 1.2 and DTLS
(and probably with something like Bryan's super encryption). Sadly,
DTLS doesn't compose with Tor and so, we want a similarly hard to
distinguish TCP protocol that does compose with Tor.

None the less - eventually a long term attacker may be able to learn
things about public websites (eg: which wikipedia page you visited) -
for non public websites, I don't believe that you can make the same
claim. Additionally, the bar for an attack has just been seriously
raised from ngrep to a pretty sophisticated attacker with long term

> You could use innocent servernames or multi-SAN server certs plus *NO* SNI.
> and both would provide higher security and be much easier to implement
> than encrypting SNI.

I look forward to your proposal that removes the need for encrypting
SNI. I think it will be interesting to compare your construction with
the soon to be shown encrypted SNI proposal.

All the best,