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

Aaron Zauner <> Thu, 03 December 2015 16:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 396DC1A8AF2 for <>; Thu, 3 Dec 2015 08:25:39 -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 jzwgfyTLhcQ4 for <>; Thu, 3 Dec 2015 08:25:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F6BB1A8AF1 for <>; Thu, 3 Dec 2015 08:25:37 -0800 (PST)
Received: by lffu14 with SMTP id u14so94088584lff.1 for <>; Thu, 03 Dec 2015 08:25:35 -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=LeiiX2bPbpJaiiCWOVmsFFAe/Kk45LJy1UnFCfMQfO8=; b=O3hxhmQJGKTsriJ//xCz5VnYkuoEVECUzODljm/dUOitj6ci3wKz7BIEksKrojwi4I R77lm/miyIo25qcj0uzLV7sD14t6GcvgBP3aWYxwSRNIHopng1XJKH/SNpBY4vvpDHiW bKg8uCwOYgtZQgRTlDns4YbgFa7+Up35KRI3w=
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=LeiiX2bPbpJaiiCWOVmsFFAe/Kk45LJy1UnFCfMQfO8=; b=fLsFR0U8Hnoa1kIwPXF5lV5Znx5AYpRh519G/LFeOd3rLRS7vAs7hfsejrm9dkkCiJ /VixlGym03BY9/RazojXpors0M9kdzAJYWKJrvL3HPtZyBUAf9pPAqbvmxniesv19/z0 lVw/NNApwPMl/y48hiEh4QbelcfhJH1jYFTg8lX6upcisfwUE+mYzaXU3e7kvfDwduR0 2P8PzQeFxBadUPB194djTvaE7aCw+yn3T6T1VCkNEUGCALiMVtPebkVhO2Ji7ayn0v35 V+FUQAmj+KLUM7gA1hGhel8dZKzTnzE5Wv1uWUEG5522n0DqcMDHJM+/32fv/1BZtM0S TH/A==
X-Gm-Message-State: ALoCoQncngJUOhQrU2d1DwfqN7RCkmUUcfWgHGQSl97CJ3HoCdTbge6mNl5bI+Imd/5kEw3e/VoA
X-Received: by with SMTP id 82mr5776257lfp.98.1449159935214; Thu, 03 Dec 2015 08:25:35 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id o67sm1554256lfo.33.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 08:25:33 -0800 (PST)
Message-ID: <>
Date: Thu, 03 Dec 2015 17:25:28 +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="------------enig6367C5FF19894AA7A01CB036"
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 16:25:39 -0000


Jacob Appelbaum wrote:
>> I don't think traffic analysis is in the treat model for TLS proper.
> I'm confused by what you mean by traffic analysis. We encrypt content
> in TLS because we know that we want confidentiality. We want that
> because we know people do basic traffic analysis looking for sensitive
> data in plaintext.

I don't work in SIGINT nor for commercial networking vendors so I always
have used jargon I picked up from Wikipedia:
Traffic analysis is the process of intercepting and examining messages
in order to deduce information from patterns in communication. It can be
performed even when the messages are encrypted and cannot be decrypted.
In general, the greater the number of messages observed, or even
intercepted and stored, the more can be inferred from the traffic.
``` --

My example, Pond, counters this with padding, randomized traffic
patterns and - of course - Tor [0]. I'm just saying this is unpractical
for a low-latency protocol such as TLS. I think we all agree there.

> There are many kinds of traffic analysis adversaries. I think TLS
> isn't trying to beat a global active adversary, for example, while
> also providing anonymity. It seems that TLS is trying to beat a global
> passive adversary from violating the confidentiality of the protocol.
> A lack of confidentiality in many cases allows for attackers to do
> better traffic analysis and selective denial of service attacks.
> Failure to deal with very simple traffic analysis leads to much more
> serious attack vectors being actively exploited in the wild.

See my last message, I'm absolutely for encrypted-SNI. If it's feasible.
If we end up with some compromise, maybe. But what we have now is
nowhere near ideal.

BTW, I played with SNI DoS a few months back (not too much though as it
wasn't worth a paper), seems not to be as bad as it used to be because
implementations nowadays have at least some counter-measures.

> The architecture of the network protocol is the politics. There is no
> separation.
> RFC1984 and RFC 7258 cover this topic nicely.

Bashing on random companies won't get us anywhere. I agree with you, but
it's off-topic here. Most of the participants here do not represent
their employer and even though some might have made a bad employment
choice, it's up to them. They mostly speak for themselves and bring
valuable implementer opinion to the table. Some break TLS on a massive
scale and this is a problem (we have a vendor-nickname for a certain TLS
extension after all). See also RFC7624, RFC7696.


[0] -
       (Ctrl+S "traffic profile")