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
- [TLS] Encrypting record headers: practical for TL… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Tony Arcieri
- Re: [TLS] Encrypting record headers: practical fo… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bill Cox
- Re: [TLS] Encrypting record headers: practical fo… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Short, Todd
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Jim Schaad
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… John Mattsson
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- [TLS] Fully encrypted and authenticated headers (… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Fully encrypted and authenticated heade… Martin Thomson
- Re: [TLS] Fully encrypted and authenticated heade… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Mike Copley
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Stephen Farrell
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Ilari Liusvaara
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Mill
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Martin Thomson
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jeff Burdges
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum