IETF Logo Mail Archive

Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

Joe Touch <touch@isi.edu> Fri, 29 July 2016 21:23 UTC

Return-Path: <touch@isi.edu>
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 E875112D86F; Fri, 29 Jul 2016 14:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.187
X-Spam-Level:
X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 XfZ8XkbIYU7b; Fri, 29 Jul 2016 14:23:28 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 E3C0E12D798; Fri, 29 Jul 2016 14:23:28 -0700 (PDT)
Received: from [128.9.184.41] ([128.9.184.41]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6TLM6O3003747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2016 14:22:09 -0700 (PDT)
To: Brian Trammell <ietf@trammell.ch>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie> <A0A36FD7-3494-4BC3-9C68-FD58A55DF087@trammell.ch>
From: Joe Touch <touch@isi.edu>
Message-ID: <579BC8FC.2000005@isi.edu>
Date: Fri, 29 Jul 2016 14:22:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <A0A36FD7-3494-4BC3-9C68-FD58A55DF087@trammell.ch>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/sqhGj_X7k1CdeviihnYiirlHqEk>
Cc: privsec-program@iab.org, spud <spud@ietf.org>
Subject: Re: [Spud] [Privsec-program] 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 21:23:30 -0000


On 7/29/2016 9:22 AM, Brian Trammell wrote:
> hi Stephen,
>
>> Hi Brian,
>>
>> On 29/07/16 13:33, Brian Trammell wrote:
>>> Greetings, all,
>>>
>>> During the PLUS BoF last week, concern was expressed that a generic
>>> signaling mechanism such as proposed opened two new attack surfaces:
>> ...
> Agreed that the analysis isn't where I'd like it to be yet. There are two major reasons for this. One, this draft is focused on in-band abuse of TCP and IP features (which seemed a good place to start) 

I don't think it is.

A user who doesn't want this sort of vulnerability inside the messages
they send needs to use integrity protection at least (perhaps also
encryption).

A user cannot prevent vulnerabilities in layers they can't control
(e.g., along a tunnel used along a subset of the path).

It's not productive to try to analyze the weaknesses of protocols that
are not designed to be strong. They're weak. Move on, IMO.

The alternative is "hey, it's weak - we should make it strong". Doing
that ends up violating the Postel Principle. I.e., behaviors that are
otherwise legitimate are suddenly interpreted as deliberate and
malicious attacks when they were never specified as such.

That's not helpful, IMO.

Joe

v2.23.0 | Report a Bug | By Email