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

Jacob Appelbaum <jacob@appelbaum.net> Wed, 02 December 2015 12:38 UTC

Return-Path: <jacob@appelbaum.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ABA1A8987 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 04:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT-7i7QkU1W9 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 04:38:55 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D75C1A8983 for <tls@ietf.org>; Wed, 2 Dec 2015 04:38:55 -0800 (PST)
Received: by ioir85 with SMTP id r85so43763804ioi.1 for <tls@ietf.org>; Wed, 02 Dec 2015 04:38:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.107.138.28 with SMTP id m28mr4005094iod.24.1449059934711; Wed, 02 Dec 2015 04:38:54 -0800 (PST)
Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 04:38:54 -0800 (PST)
X-Originating-IP: [195.154.216.143]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <CAFggDF03fzyAw95Ka8NHtBGEcebAe3RCt5pRd3r8_nhBbR7oNw@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz>
Date: Wed, 02 Dec 2015 12:38:54 +0000
Message-ID: <CAFggDF2ZqXBN__gbY-3m9fDOX4s8Z=R-+HPz06h-c1QDYkTqbQ@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Za59f16rK9vquyyWicQZEHqDLlw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2015 12:38:56 -0000

On 12/2/15, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Jacob Appelbaum <jacob@appelbaum.net> 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,
Jacob