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

Ted Hardie <ted.ietf@gmail.com> Fri, 29 July 2016 21:14 UTC

Return-Path: <ted.ietf@gmail.com>
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 69A3A12D5FC for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 14:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 X2JAq3tuNVCZ for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 14:14:52 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 9BCFB12D531 for <spud@ietf.org>; Fri, 29 Jul 2016 14:14:52 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id l65so122641648oib.1 for <spud@ietf.org>; Fri, 29 Jul 2016 14:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l8njyNMulQn69BMMwp1BKkoudQmIxbpTnBFQLhdLusI=; b=jt4RvwpW4gZMoyn3G/wybpU8H3tJlan7P0ozIckbFS1V7Xw68FAPTvbbxvDPOtjZQi 2ciedOGAG/rUyRDoEp06mqRNMGwLxU7d8E1sxzy1jsDsyzO9gIbkiv9049TV1vgs7seZ 7vFppxrt4QQSq5nJ/6m189BPQKCAsWItYB4b//DUFPtXIpQI/6x0G7CTe2g2CUNnweld ftEWR9meuIkpwSh/nuN7k2HcapsKGtUb94esLEjLD8glAepjHGQl3BgkFEZFkXSaQvcC r8ZGDoSr1gzaCPo5gbs/qfHVPnHkASNmUFq7aZn8MusoYztQYGetJqHaMaBi0kbzj44A zGhg==
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:from:date :message-id:subject:to:cc; bh=l8njyNMulQn69BMMwp1BKkoudQmIxbpTnBFQLhdLusI=; b=C/RXf69M1/QSCcmyF/C2DzxrO/wwqPIJUfeX+n7Ugozu4xr8fQwM4/Vpgstvi4pc97 y/g3W6Pfoxlw6wGCz9M+6YEBWi/6w9cBFd9Y6B+MfKiXwf+Nwyg3YlkyxVsbmh+kj0iZ xYJ06pAlgBRK4xnRloDRPamr82aZNJaE9aOEMBT++YCbGJ7W0aw4PtQ521S0jsgmwa6m dvPBDP6d7YGk01p8EE018N8L/1RVLtOs14+l8Ur3PGBIvRbfKkHppF1vCRNqJs40Pq3i sghscWYdNU8H2VVcj8vI8wvX3KCASPS8kVzGy/zEx+MssKZuay2qDWNlN0Hp+UDzPQHJ 0vvQ==
X-Gm-Message-State: AEkoouvq4GoP1dGUdspHlBGGd5mOwxuwpovoj6u/7+GKB7So+xFUhfKHCrVPqwguQTlDzmZZxZ5k85ssqtFEjg==
X-Received: by 10.202.68.6 with SMTP id r6mr26245296oia.53.1469826891964; Fri, 29 Jul 2016 14:14:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.222.213 with HTTP; Fri, 29 Jul 2016 14:14:22 -0700 (PDT)
In-Reply-To: <205d99b2-4246-4a77-35f0-7c8a86a1ceed@cs.tcd.ie>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <dc29fa73-88fd-3dc4-7497-f1bd2fa60422@cs.tcd.ie> <CA+9kkMDaamgb_qZkmAMvU9-6ACwt3-GFKBkOprD+HcK=QLSupg@mail.gmail.com> <205d99b2-4246-4a77-35f0-7c8a86a1ceed@cs.tcd.ie>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 29 Jul 2016 14:14:22 -0700
Message-ID: <CA+9kkMDDjqgvtXzqhFDgiTJKhUq5eQv_haRS-_G7RAHahaTpZw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a113d6f46c6eb2f0538ccbd27
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/UoaUePn_VzqxvocU0pYK1QEOlsA>
Cc: Brian Trammell <ietf@trammell.ch>, "privsec-program@iab.org" <privsec-program@iab.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, 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:14:55 -0000

On Fri, Jul 29, 2016 at 1:40 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

>
> Hiya,
>
> >
> > The folks arguing for this have a set of concerns:
> >
> > *) Some useful path elements are impaired now, compared to
> > previously.
>
> FYI, I find the term "impaired" scarily vague in this context. It could
> mean anything from "0.1% less reliable" to "no longer allows me assert
> that the person using the machine is over 18." That lack of specificity
> and the absence iiuc of public data describing the claimed impairments
> damages the argument of the PLUS proponents here.
>
>
The specific impairments vary over the type of network, but the class is
"consume more resources than previously".  Resources here can be radio
bandwidth, power from a total radio power budget, delay intolerant queue
slots, state table size, and so on.  Note that these impairments have
implications for the end systems as well, as the hoary example of UDP
heartbeat traffic and NAT state shows.


> > How can we safely repair that impairment?
>
> That depends on what is considered impairment and without a shared idea
> of that I don't think we can get to an answer.
>
> Does the class given above help?



> > Where safely means:  not restoring
> > plaintext for inspection nor providing a worse-than-current side
> > channel for identification.  (I accept that analysing one against
> > "current" requires understanding ease of attacking the side channel)
> >
> > *) If there is a new, popular transport protocol, how do we ensure
> > that it does not end up as the new HTTP, used for a variety of things
> > not because it is suitable on design fit but because it gets through
> > the network?
>
> (Aside: if new transports are as successful as http, then we're making
> progress I think:-)
>
>
QUIC has that potential, if the race against HTTP/2 tests so far are any
guide.

> To put this another way, how do we make sure that the
> > new design pattern given above opens innovation at that transport
> > layer?
> >
> > While the proponents of PLUS believe that a substrate approach is the
> > most deployable (because you can redefine things like SRTP to run
> > over PLUS instead of bare UDP), we care much more that the approach
> > meets those concerns than the approach be a substrate.  If you want
> > to call it a "design pattern" and implement it in a couple of
> > candidates from that design pattern, fine.  You end up describing the
> > thing multiple times rather than once, but cut and paste is a fine
> > tool.
>
> I agree with your last there. I actually think cut'n'paste is likely
> a better approach here - it means that one can evaluate the essential
> signals in each case, whereas the substrate/shim approach requires
> that one has that dangerous extensibility. And for what real value?
>
> I'm not sure that the substrate/shim approach does require dangerous
extensibility; if we limit it to get what's needed, we may avoid the
danger.  And the value is the usual:  common libraries, common APIs, and
common understandings of the threat model.


> >
> > Does this description make sense to you?  Or are we still a bit at
> > cross purposes here?
>
> Aside from the vagueness in "impairment" I think I understand it yes.
> (And this may be a thing where it's possible to not be talking at
> cross purposes and yet still disagree as to whether there ought be
> any path forward at all for PLUS.)
>
>
regards,

Ted


> Cheers,
> S.
>
>
> >
> > Ted
> >
> >
> >
> > _______________________________________________ Privsec-program
> > mailing list Privsec-program@iab.org
> > https://www.iab.org/mailman/listinfo/privsec-program
> >
>
>