IETF Logo Mail Archive

Re: [Coin] challenges for COIN

Carsten Bormann <cabo@tzi.org> Fri, 01 March 2019 16:02 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4612894E for <coin@ietfa.amsl.com>; Fri, 1 Mar 2019 08:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 Oik5LGKCKPnw for <coin@ietfa.amsl.com>; Fri, 1 Mar 2019 08:02:25 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692BC124C04 for <coin@irtf.org>; Fri, 1 Mar 2019 08:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x21G2GxD006299; Fri, 1 Mar 2019 17:02:21 +0100 (CET)
Received: from [134.102.172.19] (unknown [134.102.172.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 449vLw52ZZz1Bp8; Fri, 1 Mar 2019 17:02:16 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <AFB99EE1-699B-45CA-88F2-8DE2B53D802A@dkutscher.net>
Date: Fri, 01 Mar 2019 17:02:14 +0100
Cc: coin@irtf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <72D8741F-C415-4947-8B73-7EC224D04058@tzi.org>
References: <AB07990D3CAE53419132AB701C45693CD6F3DA2E@dggeml529-mbx.china.huawei.com> <AFB99EE1-699B-45CA-88F2-8DE2B53D802A@dkutscher.net>
To: Dirk Kutscher <ietf@dkutscher.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/RlwoWCnaTeGvGKlJhL5jqRqGhXw>
Subject: Re: [Coin] challenges for COIN
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 16:02:28 -0000

On Mar 1, 2019, at 13:25, Dirk Kutscher <ietf@dkutscher.net> wrote:
> 
> Let’s please forget the notion of “managed networks where privacy and security is not a big problem”.

+1 (with a very big ONE).

The usual approach here, however, is

(1) Somebody dreams up something under that flawed assumption
(2) This something gets deployed
(3) Security breaches start to get noticed
(4) Some very weird usage restrictions are dreamt up to “manage” these security breaches
(5) Insecure something plus the straightjacket from (4) becomes the new normal
(6) This becomes the way “real networks are run” by “real engineers”
(7) All this cannot be questioned any longer and becomes a drag on any further development.

Examples are galore.  I’d offer RFC 6092…

The flip side of the coin [sic] is that, for research, it is usually quite useful to ignore some requirements, and that may include security.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email