Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? (Martin Rex) Thu, 03 December 2015 16:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 951861A9149 for <>; Thu, 3 Dec 2015 08:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.151
X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BlnISA_B3rbk for <>; Thu, 3 Dec 2015 08:53:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60EEE1A9233 for <>; Thu, 3 Dec 2015 08:53:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FAAD2B1DC; Thu, 3 Dec 2015 17:53:45 +0100 (CET)
X-purgate-ID: 152705::1449161625-00001C04-6FD0736B/0/0
X-purgate-size: 1815
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id D9230408F6; Thu, 3 Dec 2015 17:53:44 +0100 (CET)
Received: by (Postfix, from userid 10159) id C639C1A3A0; Thu, 3 Dec 2015 17:53:44 +0100 (CET)
In-Reply-To: <>
To: Jacob Appelbaum <>
Date: Thu, 03 Dec 2015 17:53:44 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
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 16:53:49 -0000

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.

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.

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

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.