Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks
Stephan Neuhaus <sten@artdecode.de> Fri, 29 July 2016 19:52 UTC
Return-Path: <sten@artdecode.de>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6112DAFC for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 12:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 45kkD0Z9aSPq for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 12:52:21 -0700 (PDT)
Received: from wp214.webpack.hosteurope.de (wp214.webpack.hosteurope.de [80.237.132.221]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27DD12DAEC for <spud@ietf.org>; Fri, 29 Jul 2016 12:52:20 -0700 (PDT)
Received: from [31.10.157.197] (helo=mairac.home); authenticated by wp214.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1bTDpT-0007MY-4S; Fri, 29 Jul 2016 21:52:19 +0200
To: Tom Herbert <tom@herbertland.com>, Brian Trammell <ietf@trammell.ch>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <CALx6S37s-FM13seA28vd_gahYJbqo_sq+RB-S5LEzKRCYKzh0w@mail.gmail.com> <A29F376F-3775-4E48-97EE-2DD4208ADC0C@trammell.ch> <CALx6S35G3UPcAj_Wt+zNDH2vbakiXrXPpRJR0XmW-5Kn4-tVeg@mail.gmail.com>
From: Stephan Neuhaus <sten@artdecode.de>
Message-ID: <05118b58-8bf9-8abc-b6bf-2d2b0b79d8ef@artdecode.de>
Date: Fri, 29 Jul 2016 21:52:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CALx6S35G3UPcAj_Wt+zNDH2vbakiXrXPpRJR0XmW-5Kn4-tVeg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-bounce-key: webpack.hosteurope.de;sten@artdecode.de;1469821941;2816ded2;
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/wTsOu-adcpaG6Mvc5pTadGGVtzs>
Cc: spud <spud@ietf.org>
Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2016 19:52:23 -0000
On 2016-07-29 19:12, Tom Herbert wrote: > On Fri, Jul 29, 2016 at 9:29 AM, Brian Trammell <ietf@trammell.ch> wrote: >> >> Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals. (Okay, I might need to hack the kernel on my middleboxes. But I get to do that. They're mine. :) ) >> > Except that middelboxes presumably do not have access to the encrypted > data so the amount of information they can derive from the packet is > limited. The problem is when the application or user is being coerced > and there is a readily available mechanism that facilitates that. For > example, it seems very possible that a rich signaling mechanism > implemented by the user could be used to enforce a backdoor to > encryption. Now I'm confused. I thought that the situation that Brian was talking about is middleboxes fiddling with the packet headers, which are in plaintext, and not with the packet's payload which, as you say, may be encrypted. You seem to be saying that the amount of information that can be extracted from plaintext transport headers is limited, is that correct? Brian is also talking about the path; you seem to be talking about the endpoints, is that correct? If both these assumptions are correct, then I'd like to make three points. (If they're both wrong, please stop reading. If one is right and one is wrong, read only half of what follows. You choose which half :-) ) First, I do not agree that the amount of information in the transport headers is limited, which I assume means "of limited value". It's classic metadata and should be protected, if possible. That transport header is seen by many more boxes than the plaintext of the encrypted payload and thus the probability of someone siphoning it off are that much larger, precisely because it is valuable. Second, I'm not sure in what way "a rich signaling mechanism implemented by the user could be used to enforce a backdoor to encryption" or rather, I'm not sure how that is a problem enabled specifically by PLUS. If the "user" (which I understand to be an application running on top of a networking stack) wants to "backdoor its encryption" (i.e., leak key material), it can already do so today. For example, a suitably modified TLS library could stash the master secret at the end of a TLS message (may work with many applications, even without an equally compromised TLS library on the other end). Or it could silently always use DUAL_EC_DRBG (always works). Or ... Many of these would go undetected for a long time. The upshot is: once your endpoint is compromised, all bets are off anyway. And finally, have the impression that you think that PLUS is going to be this gigantic free-for-all, where every Joe, Dick, and Harry can annotate a packet in any way they please. If I understood the PLUS proponents correctly, this will not be the case. PLUS fields will be limited in number, space, and semantics, and they will (for the most part) be integrity-protected so that nothing on the path can fiddle with them without anyone noticing. To summarise: 1) If your endpoint is compromised, you're screwed anyway. 2) The total amount space that's available for undetected fiddling by a middlebox will perhaps not be zero, but it will be less than it is today. Fun, Stephan [Full disclosure: I'm working with Brian and Mirja on the MAMI project.]
- Re: [Spud] Extensibility considered harmful? was … Kyle Rose
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- [Spud] Detecting and Defeating TCP/IP Hypercookie… Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephan Neuhaus
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] Extensibility considered harmful? was … Kyle Rose
- Re: [Spud] Extensibility considered harmful? was … Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Christian Huitema
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Christian Huitema
- Re: [Spud] [Privsec-program] Detecting and Defeat… Spencer Dawkins at IETF
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Spencer Dawkins at IETF
- Re: [Spud] Extensibility considered harmful? was … Ted Hardie
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- [Spud] Extensibility considered harmful? was Re: … Brian Trammell
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Spencer Dawkins at IETF
- Re: [Spud] [Privsec-program] Detecting and Defeat… Michael Tuexen
- [Spud] Extensibility considered harmful? was Re: … Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Christian Huitema
- Re: [Spud] [Privsec-program] Detecting and Defeat… Michael Tuexen
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Michael Tuexen
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephan Neuhaus
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Joe Touch
- Re: [Spud] [Privsec-program] Detecting and Defeat… Ted Hardie
- Re: [Spud] [Privsec-program] Detecting and Defeat… Ted Hardie
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Stephan Neuhaus
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Tom Herbert
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell