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

Yoav Nir <> Wed, 02 December 2015 07:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D0F751A86E3 for <>; Tue, 1 Dec 2015 23:05:09 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4xMwExvWBCvS for <>; Tue, 1 Dec 2015 23:05:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAD5E1B33B0 for <>; Tue, 1 Dec 2015 23:05:05 -0800 (PST)
Received: by wmec201 with SMTP id c201so238783844wme.0 for <>; Tue, 01 Dec 2015 23:05:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9smxgpuWyFgnba6C5YxuV1lEo6yRmuwOF2PFFqvPrQ4=; b=yO2O5Y7LvSurhpZQTJlBwn5LD++WSk27aeyohemI/4XJXlg5poT1Ct8N9PxXDf0I7x oViJC5UyPmbRO2z13CMO4OuluhZB2w7dVp0OSAQUZ0haUKuxdholRok5NqMeAzSPHSNc aZ9RXMWCqr/iU63pilJULVdYKNchfKJuJDwbApgIqdXF+xV/zfbfZCCO8ckzexRblRqD tNOIT2kXV06oHHcG7bLBQJF22Z4BsFDwAcs1epBLEB2ArKzNFdsgOTv3NOSa5RRPeQc3 Ra7otHth5ZTdxoVZtPdmdcfKJ6dMBWuBtCYRN4s2I3WjQZnsKDeLyzoj3EFvMrvNEI4d 2nlg==
X-Received: by with SMTP id ft19mr2440681wjc.176.1449039904364; Tue, 01 Dec 2015 23:05:04 -0800 (PST)
Received: from ([]) by with ESMTPSA id z10sm29533048wmg.4.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 23:05:03 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 09:05:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.3096.5)
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: Wed, 02 Dec 2015 07:05:10 -0000

> On 2 Dec 2015, at 3:24 AM, Peter Gutmann <> wrote:
> 1. Define a threat model.  What are we supposed to be defending against?
>   (Note: The Inside-Out Threat Model, "this is the defence, anything that it
>   prevents is what we're defending against", is not a threat model).

Fine. I’ll take a stab at it. But different people are concerned with different threats. So I’ll divide this into three layers of concern, because I think they build one on top of the other:

Concern Layer #1: I would like a passive observer to not be able to know the exact size of requests and responses in my stream as that could identify the resource name and content. Obvious example is from HTTPS. At this layer I’m fine about “them” (for whatever “them” I’m concerned about) knowing that I am browsing Wikipedia, but I don’t want them to know which article.

Concern Layer #2: I would like a passive observer to not be able to know how many requests I am making to the server at a given time. At this level I’m concerned that just the number of requests may leak something about what I am looking at. So if I’m looking at one of only 12 Wikipedia pages that have exactly 27 images it severely narrows down the list of what I’m looking for. 

Concern Layer #3: I would like a passive observer to not be able to know whether I am sending requests and getting responses at all. Obviously they can know that I have an HTTPS connection with, but they should have no idea whether this connection is idle or downloading tons of content. 

I could add a fourth layer where I don’t want the observer to know whether or not I am looking at Wikipedia at all, but that is not something that I believe the TLS working group can do. This is more in-line with what Jacob is doing.