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

Bryan Ford <> Wed, 02 December 2015 10:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60EB51A7012 for <>; Wed, 2 Dec 2015 02:03:48 -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 onAgc12-gJUX for <>; Wed, 2 Dec 2015 02:03:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D99391A700D for <>; Wed, 2 Dec 2015 02:03:44 -0800 (PST)
Received: by wmvv187 with SMTP id v187so246688608wmv.1 for <>; Wed, 02 Dec 2015 02:03:43 -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 :message-id:references:to; bh=wU6RT2nKOOG9EZncPgx+MnsEOXhLVc/dq4zusR3HFnY=; b=JO5Wd2BphhkvTFWwX8vLnmP9RIxFsBm1p/IF4NhFa71WQ5utWIHIWDQPQXkA2ZHPe2 bg2CDk2bs+d7wwhH9rlG/qaqZpppvf62q9AOEMg0K6p0UmCG6XWTsKqa1TKzSKLPHMRP 6XhSLtYCCKLpX3zjg8NBNa8xIwvwItFnkYQw7YLLPTH+plJQC1eFFIU3EssmZBnJHMwL eldTZliyoYEieNcSy/0KFQSK17QvIro14ds1m3P31UtdAkH+3FVCCRWFxKBg4ptYCuqG Kn2qkIp3jX53bysRgvfhiJP0MzSrY8Clni6FBR6yfmfAXBBIlZOqH4mpDqsUGemTewuo d00A==
X-Received: by with SMTP id y66mr43373028wmb.98.1449050623476; Wed, 02 Dec 2015 02:03:43 -0800 (PST)
Received: from ( []) by with ESMTPSA id h5sm2023281wjz.21.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 02:03:41 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1C6FA78C-AD92-4027-B02D-7A4321012FB7"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Bryan Ford <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 11:03:41 +0100
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 10:03:48 -0000

On 02 Dec 2015, at 02:24, Peter Gutmann <> wrote:
> Jacob Appelbaum <> writes:
>> I think the only thing that comes close is when I've named a classified US
>> government surveillance program (XKeyscore) that would probably have trouble
>> with it.
> Why would XKeyscore have trouble with it?  Standard off-the-shelf routers, not
> even specialised USG surveillance gear, does fairly sophisticated flow
> tracing, packet reassembly, connection analysis, and so on.  It's built into
> the router.  Encrypting the headers is, at best, a minor speedbump to
> attackers (while being a major headache for implementers, particularly SSH's
> way of doing it), because they can use the native capabilities of the routing
> hardware to sidestep the need to decrypt headers.
> If people really want to address this then they need to do the following:
> 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).

We have repeatedly stated several relevant threat models here; you just don’t seem to be accepting them as threat models for some reason.  One is the passive eavesdropping attacker, who can monitor flows but cannot easily inject traffic; mass monitoring of tapped fibre optic cables are one specific real-world example of that.  Another is the “partly-active” attacker who can inject packets but cannot readily prevent the legitimate packets from arriving; two very real-world examples of this are XKEYSCORE/QUANTUMINSERT and the WiFi internet cafe snooper.  In each of these real-world threat models the “dribble attack” to sniff out record boundaries via full MITM is not an option for the attacker, and hence there is potential benefit to encrypted record headers even without any other anti-traffic-analysis measures.

> 2. List the various measures that can be used to defend against the threat:
>   Fixed-size packets, padding, quantised packet timing, etc.

We have been doing this as well, repeatedly.  And as I’ve stated repeatedly and you have not refuted, having encrypted packet headers allows us to deploy some of those defense measures in multiple places in the network (e.g., TCP stack and/or middle boxes) rather than just one (TLS implementation).