Re: [arch-d] ipv4 and ipv6 Coexistence.

Toerless Eckert <tte@cs.fau.de> Wed, 26 February 2020 21:00 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D063A14A4 for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Feb 2020 13:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 gj7_aqMQNCOG for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Feb 2020 13:00:54 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872153A1498 for <architecture-discuss@ietf.org>; Wed, 26 Feb 2020 13:00:54 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 61EB8548048; Wed, 26 Feb 2020 22:00:48 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5CC61440040; Wed, 26 Feb 2020 22:00:48 +0100 (CET)
Date: Wed, 26 Feb 2020 22:00:48 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, architecture-discuss@ietf.org
Message-ID: <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de>
References: <EDAE6375-EE0B-4864-9834-C1FBC209D581@sobco.com> <PR3P194MB08431E138262F2A43C1D0621AE100@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es> <PR3P194MB0843939F3B38426960A66E70AE130@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <D8063303-7DDA-41F8-A63A-C0244E3E9E25@isc.org> <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com> <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/yRD41JhHQg1BbBaT29PKvO5sPO4>
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 21:01:04 -0000

On Wed, Feb 26, 2020 at 10:45:29AM +0000, Stephen Farrell wrote:
> On 26/02/2020 10:21, Stewart Bryant wrote:
> > "The head of MI5 has urged technology companies to give the security
> > services â?????exceptionalâ??? access to encrypted messages 
> 
> And in other, equally shocking, news: the sun will rise tomorrow;-)

https://en.wikipedia.org/wiki/The_empire_on_which_the_sun_never_sets
;-))

> If you do want to rehash the cryptowars debate again,

Not at all. But for example enterprises often use HTTPs proxies
for firewalling, intrusion detection, proprietary data leakage
prevention and the like. I am not aware we have stablished standards
for such desirable behavior. In fact there are issues with the expected
end-to-end krypto security when you bring in such trusted middle-men.
(e.g.: undesirable cert spoofing). There are no browser standards
for a three party trust-model AFAIK.

Right now, we have only those global commercial players positioning
them as trusted third parties. Even DoH IMHO falls into this play.
And then selling customer data collected, at least when they have
some entity operating outside europe (GDPR data leakage prevention).

All those IoT devices that export unbeknownst do the user all type
of collected user data to a cloud. We could come up with mandatory
published data models, force the connection through a trusted third
party device that can then do semantic filtering. Aka: i rather
want to be able to control than just trust GDPR statements.

Likewise i think we could define better behaving firewall policies
in the fashion did it for NAT with BEHAVE, e.g.: more visibility
of policy for better diagnostics.

Etc. pp. Just brainstorm what positive evolution we could promote
through IETF work for more security. The IETF end-to-end encryption
laurels nice but not enough.

> maybe at least change the subject line? If doing so,
> and I hope you decide not to, because there's no gain,
> please recognise that there are many (me included) who
> do not share the views you quoted for sound technical
> reasons (e.g. [1] is perhaps the most-cited recent
> paper on that) that have garnered rough consensus in
> the IETF every time we've done that rehashing.

Stating that we would like to see IETF solve problems doesnt
mean we agree to those regurgitated security agency memes.
Instead, i see these memes as the real risks, because the
public has shown to give in to the ongoing "tough on crime"
pounding with really bad outcomes. So we really need better,
alternative models for more security in addition to the
ongoing push back against that type of nonsense.

Cheers
    Toerless

> S.
> 
> [1] Abelson, Harold, et al. "Keys under doormats: mandating insecurity
> by requiring government access to all data and communications." Journal
> of Cybersecurity 1.1 (2015): 69-79.
> https://www.cs.yale.edu/homes/jf/paper-keys-under-doormats-CSAIL.pdf
> 
> 
> 
> 
> 

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie>
> sub   RSA 4096/36CB8BB6 2017-12-22
> 




> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss


-- 
---
tte@cs.fau.de