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

Jacob Appelbaum <> Thu, 03 December 2015 16:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A29A81A8F3D for <>; Thu, 3 Dec 2015 08:04:40 -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 jLYSrZpg9hKx for <>; Thu, 3 Dec 2015 08:04:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6D511A8BC0 for <>; Thu, 3 Dec 2015 08:04:34 -0800 (PST)
Received: by ioir85 with SMTP id r85so85711301ioi.1 for <>; Thu, 03 Dec 2015 08:04:34 -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=dK1WRk1qq4OkiHHEh7utaFQ/ytOqmXSdpyRsYU7HsGE=; b=h0TR/WbpCyxP/zroIv6UnZ6ZU0sGnmj74ot8vMCEh2RUTNWxZiiWAWCjRhSmPOfqU1 RrHbUtRnEdD9YCvaDfGwuuSWiJo2l9VfUpR48TifNchXXyOpG3P9zobCHg51onKyHnJS W1WMUF6L4QikAirk+dTaNVat6C1Cs9KuGP89tIS9BByYHmAT1DSh2IOsNEXvl06aGN5V 06w1K82XLFz/VebDRxhQZToBPy3Lz0f4JGE6jupJfI/m81/gXHZT1k+3sueyTFy03Sti eqdTU0njqFRDxMsNF03Qd6hZM+B9YIXHvEc059B/4sJqFlIcuZfAgrXS2CRe9/GYjLvt j7pw==
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=dK1WRk1qq4OkiHHEh7utaFQ/ytOqmXSdpyRsYU7HsGE=; b=PimAqqrOq8eGot+6/IievzJY/0F8lJyxEEKhugVAM5eurBcreGN6tptOeoJVfLvyH8 dIUSYOrC3sAb/j5gScuXMLX0MHW7Eb6npLLHaemxldJozRcYs44VjTkvjLhXuMQTiuAN S0mRtY76qn6ggm7aoQNnL3NsTdf9PBNEgh8cLGpOgxHZ2LR95i2ClFCKF9t3wEzf7prn WyfpCGF9Xrw2qL86naM75RMFbRE+cEBJ7UEl3ozoOCp8mBEafg/yRWiS2C3Xru8sxyYh egrRJRhsTCh9ev0wK21s+TlRRhJiybbeeXCPD+7dTd5v+XUVIq+MT0Q+uYBMcpb8lUBF I2Jg==
X-Gm-Message-State: ALoCoQlIcaY2aKEWcQESyIMMos1Bd0ys1aHUquq9WUqQbH68s+/zogEJ33/+OL9zF9M81+j+bJue
MIME-Version: 1.0
X-Received: by with SMTP id m28mr11277756iod.24.1449158674250; Thu, 03 Dec 2015 08:04:34 -0800 (PST)
Received: by with HTTP; Thu, 3 Dec 2015 08:04:33 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 03 Dec 2015 16:04:33 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Aaron Zauner <>
Content-Type: text/plain; charset="UTF-8"
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:04:40 -0000


On 12/3/15, Aaron Zauner <> wrote:
> PS:
> Aaron Zauner wrote:
>> 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.
> 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.

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.

>  If
> we wanted to circumvent traffic analysis we'd have to introduce noise
> and randomness (Pond does a good job there using Tor and other
> mechanisms). I don't see how we can engineer a low-latency (now even
> 0-RTT) network security protocol that will do that in a performant
> manner. When time comes and people have 10-40-100GE at home, maybe.
> Infiniband would be nice. But that will still leave out use for 3rd
> world countries (which still run on XP anyway). This is a technical list
> and we should keep politics and FUD aside as best as possible.

The architecture of the network protocol is the politics. There is no

RFC1984 and RFC 7258 cover this topic nicely.

All the best,