Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
Stephen Kent <kent@bbn.com> Mon, 20 January 2014 15:11 UTC
Return-Path: <kent@bbn.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4401A0186 for <perpass@ietfa.amsl.com>; Mon, 20 Jan 2014 07:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.136
X-Spam-Level:
X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
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 0upJIvIQ2Nj8 for <perpass@ietfa.amsl.com>; Mon, 20 Jan 2014 07:11:47 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B91A00DE for <perpass@ietf.org>; Mon, 20 Jan 2014 07:11:46 -0800 (PST)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54468) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1W5GVk-000O75-Gc; Mon, 20 Jan 2014 10:11:36 -0500
Message-ID: <52DD3CAA.6010004@bbn.com>
Date: Mon, 20 Jan 2014 10:11:38 -0500
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Theodore Ts'o <tytso@mit.edu>, Phillip Hallam-Baker <hallam@gmail.com>
References: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk> <CAMm+Lwj0r3PNoBC0Y1ydibD3piioZ57Z1Ks-Ea6o58xahjXKwQ@mail.gmail.com> <20140116192320.GD32098@thunk.org> <52D84F68.7030100@cs.tcd.ie>
In-Reply-To: <52D84F68.7030100@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Adrian Farrel <adrian@olddog.co.uk>, perpass <perpass@ietf.org>
Subject: Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2014 15:11:53 -0000
Stephen, > Hi Ted, > > On 01/16/2014 07:23 PM, Theodore Ts'o wrote: >> That may be true, but the alternative of edge-to-edge security is even >> worse. > I'm fairly sure you don't mean it that way, but just in case... > > We'll really be better off not to be talking as if end-to-end > (or object) and hop-by-hop (channel) security were mutually > exclusive - "the alternative" sort of implies that. > > And there are different hops or channels as well, e.g. if I > run IMAP/TLS whilst on an IPsec VPN etc etc. Or see the > discussion between Adrian and Steve Kent on our draft. So > those are also options and not mutually exclusive. no, they are not, but having a plethora of security options available does not mean that, on a pairwise basis, one will be able to invoke any of them. (Assuming that we are sticking with mandatory to implement, not mandatory to use). > One take away from a lot of the snowdonia stuff is that we > should have well defined interoperable and ideally easy to > deploy ways to do security at *every* level since every single > option will work best for someone somewhere. maybe. > For example, when the tcpcrypt folks turned up at the IETF a > couple of years ago I was against it really. That was mostly > because I figured we already had TLS so why would we want > another thing that's so similar but partly because they were > selling it as "better" than TLS. I've now concluded that I > was wrong about that and am encouraging them as I can. I wish you wouldn't encourage them. I can easily see confusion and non-interoperability arising because of the need to choose between TLS and tcpcrypt. Steve
- [perpass] Violating end-to-end principle: I-D Act… Adrian Farrel
- Re: [perpass] Violating end-to-end principle: I-D… Phillip Hallam-Baker
- Re: [perpass] Violating end-to-end principle: I-D… Joseph Lorenzo Hall
- Re: [perpass] Violating end-to-end principle: I-D… Theodore Ts'o
- Re: [perpass] Violating end-to-end principle: I-D… Dave Crocker
- Re: [perpass] Violating end-to-end principle: I-D… Stephen Farrell
- Re: [perpass] Violating end-to-end principle: I-D… Phillip Hallam-Baker
- Re: [perpass] Violating end-to-end principle: I-D… Christian Huitema
- Re: [perpass] Violating end-to-end principle: I-D… Phillip Hallam-Baker
- Re: [perpass] Violating end-to-end principle: I-D… Stephen Kent
- [perpass] tcpcrypt applicability (Was: Re: Violat… Stephen Farrell
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Dave Crocker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- [perpass] Increasingly strange thread (was: .... … Leif Johansson
- Re: [perpass] Increasingly strange thread (was: .… Scott Brim
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent