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

Jacob Appelbaum <> Wed, 02 December 2015 12:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4ABA1A8987 for <>; Wed, 2 Dec 2015 04:38:56 -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 dT-7i7QkU1W9 for <>; Wed, 2 Dec 2015 04:38:55 -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 8D75C1A8983 for <>; Wed, 2 Dec 2015 04:38:55 -0800 (PST)
Received: by ioir85 with SMTP id r85so43763804ioi.1 for <>; Wed, 02 Dec 2015 04:38:54 -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=+5khkrDiJJTxjjfJCUGkpcn2Itxm6buxyoRxpha1UDQ=; b=HnXY9PC3XoPDUznffU88tHugKoH2UvSVjaFgMrAFmg5dqBYfo0oZEW21cyZRFblUMC 2eB7QNv5SOIbJVqhAQ9SxAmWb9f7qxMoTTMf4C6P4ejxy4PDns/k79Xvy6+yB5EnXFem NTWgnlZO3kSkM6xKZuQr71/NtancxLZvPeqorpNogAXPs+6wJvxrlWSU1ur/AZ8Au2PU RUF4rmD59A2laUOrTAtp62xgBEbiCkfvqx4zObGdf1Ye3Td0ih7F2zR+b7hwGyAajDWI fC0Iup6DqwJJnB4/aaSMbOJGdBIbpfwTGI5PCW2+C3W0r6WSKFCpJnOax1X8cHjznPqi W8ZQ==
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=+5khkrDiJJTxjjfJCUGkpcn2Itxm6buxyoRxpha1UDQ=; b=eDQM0QLK6Njh71RvmhhejxNu0gNuhyhFnyNaYnUcpdpAU/k8uQ9c0uOgFvEcfKZ3Ky 0A0Cc+GVvJ5HoNGDgA9i0RUja/qgYv1TnfBX58pj9U9aY/XuiN7JbVTcFWA08Ko8gmYD dX5aoh57dItAc5lWQF8oesBk+B6dEinRBq2CKu7OJ8gQvfVtv3J39oNE2kEWacLggZd1 GenBi0t48s0uCU30sRaew4pCrpzHqPruvtUl2gog8IZVJs+8QxGItsCXRHH0mzyUSL5j rNYqUAUIZlBm2SXhGIt/tocF4IoAQmi++z/aE+qGNHtD1mN57XIbqJBcrBmH7jEclw2U e7Pw==
X-Gm-Message-State: ALoCoQkdVAkg0uLvThlUNVpan21WGIIbvWwxQqLHtX16cPan/Pj7xdV/h8n3r6+q6PFL5tQOAp8O
MIME-Version: 1.0
X-Received: by with SMTP id m28mr4005094iod.24.1449059934711; Wed, 02 Dec 2015 04:38:54 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 04:38:54 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 02 Dec 2015 12:38:54 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Peter Gutmann <>
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: Wed, 02 Dec 2015 12:38:56 -0000

On 12/2/15, 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?

My point was that we're hearing a lot of concern trolling for vendors
and the only "vendor" that has been explicitly named is XKeyscore: a
"vendor" that is without a doubt one that we want to protect against.

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

Absolutely and this proposal will do nothing to change that for on
path TLS 1.3 with TCP and probably for TLS 1.3 DTLS.

>  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 they are only a partial observer, I think Bryan's suggestion
changes the game for TLS and DTLS to leak less information. If they
are a full on path observer, they will have the full leaks of
information made possible from TCP. Thus when composed with an
anonymizing service, we'll find that these changes contribute to a
full solution.

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

A global passive adversary with a partial view is already harmed by
the changes that have been proposed. A global active adversary with a
partial view would be stymied too.

Bryan has already said it in the thread and replied but I'll agree
with him: we've done it and you're seemingly ignoring it. Furthermore
some people are concerned about surveillance vendors that are not
*opt-in* by the user - rather than treating that concern as abstract,
I'd like to see what specific vendors we should help to weaken the
security properties of TLS 1.3.

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

I think this is better left in the part of the thread where Bryan
responded - so I'll follow up there next.

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

It is not an opinion that TLS is a metadata leaking protocol and it is
seems that Bryan has found a way to reduce that leakage. With DTLS and
UDP - a surveillance vendor will have very little metadata
comparatively once Bryan's solution is part of the spec.

All the best,