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

Aaron Zauner <> Thu, 03 December 2015 13:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35F9D1A702A for <>; Thu, 3 Dec 2015 05:15:25 -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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lh3c9EnG0jZv for <>; Thu, 3 Dec 2015 05:15:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0379C1A7023 for <>; Thu, 3 Dec 2015 05:15:20 -0800 (PST)
Received: by lfaz4 with SMTP id z4so90220372lfa.0 for <>; Thu, 03 Dec 2015 05:15:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=XtZ0P4XRzTlL5auVhJk4A1HwYwQiXk6H1YIdbHY8pLg=; b=ZzF5VJN2JF18JO2ctaVqWMDgox5i3VAQIB4jr1Xk3sbSS9vGb6N0jvKF4BPG2IKIjW MansaZiEt29cmrvEuf7UzumZiUIi+RyD6HZstWL6s6P/V/HNQAjuSsm4jV+Y2PweExeI SFJyiENGVpGSl5xb7g349Sxx6gGoeiA5/DPII=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=XtZ0P4XRzTlL5auVhJk4A1HwYwQiXk6H1YIdbHY8pLg=; b=DZV/v6VluHKgn/m7QL/zqlZc/M9uK7CzROJaqH7/EpPlULrj3c8OEkmSrDYZaRS2Yt 5I3+2u2L+B6r06x8BN4eF8G69bh91LR09f7wgFyNbVe/5xgwZr1Dsaf3c0+8aQkKLSm2 lf8hri4VIuzCUOEgfXYIrh1m0DHNIsE7w7fRdJEtHelYR+NXduhpMxOyxALWmJVElFPJ +8EtjhrPPAbZ5a1oZXgj/mZYvPWnIgtUASXXbbVwVWwHE0hlLjw+suz0tgFDqWLNreXS /IrBoUi7Osq6D3RdsVoXigpaP0Hvk209bTJwrecs4XhyhN6bWfaYMRJBMxmZbvRop3TE XJJg==
X-Gm-Message-State: ALoCoQmUD3inYBhV3TdaRKiYU6zPdlXtYJjfbXic7t2ZJ+ll4Bye6YZCIcr2yQdbC47mW+jlncIf
X-Received: by with SMTP id t78mr5754726lfd.86.1449148518073; Thu, 03 Dec 2015 05:15:18 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id qp7sm1378793lbc.24.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 05:15:16 -0800 (PST)
Message-ID: <>
Date: Thu, 03 Dec 2015 14:15:10 +0100
From: Aaron Zauner <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Jacob Appelbaum <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig586AE4E4C5EEA8093952812D"
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 13:15:25 -0000

Hi *,

Jacob Appelbaum wrote:
> I'm sorry but that analysis is just not a serious and rigorous analysis.

No it's not. It's a very short presentation from a TLS-WG interim
meeting. The threat-model concerns Akamai's (and other's) current and -
possibly - future use of TLS. We're not trying to build an Onion routing
protocol. Given the FUD on the Tor dev list, this is a good thing. While
the presentation might have flaws from the perspective of an Onion
routing protocol developer, it reflects the point of view of a lot of
people/companies on this list, I assume.

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

See above, different point of views on the same problem. I agree here
and think we should continue to find a proper solution for encrypted-SNI
for TLS 1.3 - if at all possible. What we currently have on our hands is
not very convincing to me.

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


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

While kind of a political/policy document I agree that IETF WG's should
follow (and participants read) it. I remember the STRINT meeting in 2014
where a lot of people were very pissed about NSA activity and we decided
we want to do something about it. If it takes a standard a few months
longer to be finished, please give it the proper amount of time for
enough people to put their ideas into it. Most people do not come up
with solid engineering solutions over night. And crypto is hard as we
all know. We should not forget that TLS has a very different
threat-model and performance assumptions than Tor though.