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

Peter Gutmann <> Wed, 02 December 2015 01:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 83C541A02F1 for <>; Tue, 1 Dec 2015 17:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5pjf2BcuDwP3 for <>; Tue, 1 Dec 2015 17:24:41 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BAD21B3046 for <>; Tue, 1 Dec 2015 17:24:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1449019481; x=1480555481; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1lx0kULs+258tXW9ODs9Y4mLVYgofZps6S0t4BH8pRs=; b=jqlqGhmxNdIWdFB5okoq8Q0g5DiSUiWBWgB8lt1uOu5pKmDJF1OpsEWU 59DYSsswOrrN6IZMnR873a5m2yF5K6hks9TRDnGI0YYoJLObto0PWd9t/ 9LqVmZ91hXbhUFct38w5hVu9qhVxNSO6nhCMEBSiJm4aHT8jEIrfn+1Ht WjJB9boGv2xQdXVvyqvFtFyxyFwDXoycwCKupHrCEL3FHfVzUMMrzRj1T IPDvlYucZLRPAUMypT/Rh6GxhmFq8u1l1CLTm4FM5NdXqkwB7dxGUYkdM yOVhWeIaWE9/FLXlSuNOSc69+JAyyf/eiIfWb6zGDIulnnDLLpe1DnbqA Q==;
X-IronPort-AV: E=Sophos;i="5.20,371,1444647600"; d="scan'208";a="57158879"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 02 Dec 2015 14:24:13 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Wed, 2 Dec 2015 14:24:12 +1300
From: Peter Gutmann <>
To: Jacob Appelbaum <>, "" <>
Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: AQHRK9MuTTIrlxrBV0e1/10aVzchP560f84AgAJn5NI=
Date: Wed, 02 Dec 2015 01:24:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
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 01:24:44 -0000

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

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

3. Decide on which ones are necessary to defend against an actual threat, and
   which ones aren't, taking into account cost/benefit tradeoffs (is the
   effort/overhead involved worth the gain?).
4. Provide guidance for TLS and SSH developers on how they can implement

Once that's done (and in particular #1 and #2), we have a framework within
which we can decide whether encrypting lengths is worth the annoyance it
creates for implementers.

Without this, the debate over encrypted lengths is, to quote Linus, nothing
more than "people wanking around with their opinions" (and yeah, that includes