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

Ted Hardie <ted.ietf@gmail.com> Fri, 29 July 2016 20:19 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 D706C12D1CB for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 13:19:03 -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 ABMhOF52wndi for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 13:19:00 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 832F512D144 for <spud@ietf.org>; Fri, 29 Jul 2016 13:19:00 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id l65so120947827oib.1 for <spud@ietf.org>; Fri, 29 Jul 2016 13:19:00 -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=aoYTLGgNtfdOLwLPY77z58tVhDW5HJ0uXBw6NbYT6tA=; b=U44vnZ9m9ojGJXWW2m9K09vcqxQheYjyFVwHWXL5Bcl/WdRI3En6zyQbC51VgmIJUf d841hRbjdXTmVkF6MSQmAj14Th15Mvz2limJl2PYuQuwamJdPNsboOcQmGuDVc8sJZyh xbmvij7puQB6G2qMQFDWF9VDzGTJ1yrqRC+002HgS8IIVZkXFuHbK0CYU16xV47TFwz7 OdEimcFIwEKc3I/UROvp9bY5oVUedTgpEhbQdplE3NwCsNrgEe8j7z7Plnh8jUcETKu1 Mv3V+G+wjc7F/YeMXImlctgL/PbO/TdtUyJt2dtfpogWw8neMRPJvfwj2C16dEZdAa7u wtbw==
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=aoYTLGgNtfdOLwLPY77z58tVhDW5HJ0uXBw6NbYT6tA=; b=b+MMK0cG7NwlLPkAoaph6HnjvcvwJPCNOGjuWcQvwYnFdGtaOQ0wzQwus5XaUXvdLm AKKR6EXRXejhym3R1L9nWD7R9/oPou3jJPGK2f18diy6l1ehm56wphMLLMQ1eilvsl5K jdDVz6y6/I61aISBM0kquPBaqfPYD533XRYsmVDH2U5L/kgXZir1lvySE9IPCKjPq8i7 RaMV32ttMCP5zuBFpoS9ADnM1v31LU488jP4Xu3RVi2qxIWA2s6T2uV2KCQyZJFPY9l0 kdHsPq7v3vNKixqezf29syFOjTc5We0WOkqc30ZcIvIPdINUxcimfIdIaJJsGLfsQRQq jzoQ==
X-Gm-Message-State: AEkoouvp3s6p/AoKgars48fAt76I9qX67IMssJGIey0x2e8zPsngY2pP9+JsGbVHNu1YmhpgzXYwCtOsOi3EGA==
X-Received: by 10.157.45.229 with SMTP id g92mr28166866otb.48.1469823539834; Fri, 29 Jul 2016 13:18:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.222.213 with HTTP; Fri, 29 Jul 2016 13:18:30 -0700 (PDT)
In-Reply-To: <dc29fa73-88fd-3dc4-7497-f1bd2fa60422@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>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 29 Jul 2016 13:18:30 -0700
Message-ID: <CA+9kkMDaamgb_qZkmAMvU9-6ACwt3-GFKBkOprD+HcK=QLSupg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=94eb2c047984f976a00538cbf52a
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/WfgHHaCYrvCUSQyVsWGAyUWiQoA>
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 20:19:04 -0000

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

>
> Hiya,
>
> On 29/07/16 16:54, Mirja Kühlewind wrote:
> > Hi Stephen,
> >
> > I see registries as a needed and valuable part of our standardization
> > process. People ignoring registries as well as things that are
> > explicitly specified in a standards document is a different problem.
>
> Registries can be a useful way to support extensibility. They can
> also be a nuisance that allow for the promulgation of crazy ideas.
> And probably lots in between and all at once;-)
>
> None of the generalities above help in this specific case where I
> remain convinced that any extensible-generic-PLUS is liable to be
> highly dangerous. (And I'm unsure if a non-extensible-PLUS can be
> usefully transport independent.)
>
>
So, it's not clear to me exactly what you mean by "transport independent"
here, so let me drill down a bit.  I think PLUS is proposed for a set of
transports that use the UDP demux (and thanks to Stuart Cheshire for a
useful shorthand for that function).  It expects that those transports will
integrity protect their transport headers and treat as confidential some
aspects of their state exchange (a multiplexing transport, for example,
might decide that the state of the flows being multiplexed should be
confidential).  A PLUS with very limited semantics (start, stop, delay
tolerant, drop tolerant) would likely be broadly applicable to that class
of transports and yet be transport independent (for that specific meaning
of transport).

The folks arguing for this have a set of concerns:

*) Some useful path elements are impaired now, compared to previously.  How
can we safely repair that impairment?  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?  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.

Does this description make sense to you?  Or are we still a bit at cross
purposes here?

Ted