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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11E171AD377 for <>; Wed, 2 Dec 2015 17:01:19 -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 H7nT39d8r-3D for <>; Wed, 2 Dec 2015 17:01:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A3C61AD374 for <>; Wed, 2 Dec 2015 17:01:18 -0800 (PST)
Received: by igcmv3 with SMTP id mv3so2572730igc.0 for <>; Wed, 02 Dec 2015 17:01:17 -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=wP0rGO7CyEuJ3MB9j2lIvMSGqc+R6Q3ea1WPHpXBGQc=; b=0mAtGlGGvkhIcU0awzvmYf0iNLriiY8OlQcOt/VAE6eyFIYpURT66tTQ2+UBSJmhNd BSWBG0UxPgArvs2fRjuxHw/D0ZeFj4UNzDNhD2oXrgK4R2/jEdOw1HjqKuJF1p8uSWNW x2vZkXxXOAcwCNmqmwBPGFQ29jPyGrxR3INJlu9gjke4VgMNIOm6bwgZhcNpjNbUuBNW dFeEAN/7kH/dheejBCxbc2bcx8vYf+cdmbGaHsp00EIYSTMCHMW3LI+HVLfZqQuigAUo qGEuSKY9weTTSD55U7NhXstfEJ4xh5aVmQ7W3chMX+OrK4afF9plulVdU5xXB96f+3+e TPfw==
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=wP0rGO7CyEuJ3MB9j2lIvMSGqc+R6Q3ea1WPHpXBGQc=; b=kFYPtAsawOM3NwE2etym+VJ9LEYgEjOJ0fxgXgYtxNjeWahZ/8lAI4z6D+JMY7yUyS V/VVZYBzH5+hSJgDcHaymgy/87xhaP4rx/riyqhBUdpXxFJ3Xz9GuLymZzb34QK9dyeg vx7sT1VIWCSC22ca0dnuBM13GnyQg/Dh+rSXuDxoX7WiWSlt/2Fp3YMjAtCaUgLbX5bi T3XWrUlEl6E9yBhuCyWmQ36JtYGBE/pKxyDP5KNkHSnmFe8SceHPGv5mqFYdCBjlSwLC H0vCBn+b4cgdzYcTwEYkJcpL4JV0zj04Fc41GhoOY4BuRZoTuuneVUi6dvSKb7CWdrsT 6ZnA==
X-Gm-Message-State: ALoCoQlnPIz4lXNnX5X+r6+Uugd5mT6E64Wt7OJCdq002OBBaPARQLtIYA87Yop3JK8rSXv4IUm8
MIME-Version: 1.0
X-Received: by with SMTP id rg1mr16175756igc.78.1449104477553; Wed, 02 Dec 2015 17:01:17 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 17:01:17 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Thu, 03 Dec 2015 01:01:17 +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 01:01:19 -0000

On 12/2/15, Martin Rex <> wrote:
> Jacob Appelbaum wrote:
>> On 12/2/15, Martin Rex <> wrote:
>>> So your client will have to know a-priori, out-of-band or be configured
>>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello
>>> with cleartext SNI.
>> I think that is false. One could easily use the "cleartext" SNI field
>> and insert an encrypted value. A hash of the name would be a simple
>> example but not a secure example, of course.
> No you can NOT do this (in TLSv1.2 and earlier), because it is entirely
> backwards-incompatible.

If I configure a vhost to respond to a sha1( and have a
way to visit sha1( in a browser, I think it doesn't even
break the spec. That doesn't really matter - the point was to suggest
that there are many ways to solve this problem. Assuming a shared key,
we can easily take a field and transform it. There are compelling
reasons to do it and there are active attackers who are exploiting the
lack of confidentiality in TLS.

> Server-side SNI can even be implemented completely outside of the TLS
> protocol stack (that is how I implemented it).

I'm curious - are you saying that if the value was encrypted... it
would become impossible to implement it outside of the TLS protocol
stack? Or is this just an aside?

>> 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?

>> and in ways that will only become worse over time. We should
>> remember that TLS 1.3, while not yet finished or deployed, is a future
>> legacy protocol.
> TLSv1.3 is looking more and more like a future market failure to me,
> worse than IPv6.

Without privacy on the internet, I'll see your market and raise you a TCP RST.

All the best,