Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 16 January 2014 21:30 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 626211AD8C4 for <perpass@ietfa.amsl.com>; Thu, 16 Jan 2014 13:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level:
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.538] 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 24KU52quRcyi for <perpass@ietfa.amsl.com>; Thu, 16 Jan 2014 13:30:31 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 32DD91AD739 for <perpass@ietf.org>; Thu, 16 Jan 2014 13:30:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C1083BE20; Thu, 16 Jan 2014 21:30:17 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r471bGC355R; Thu, 16 Jan 2014 21:30:16 +0000 (GMT)
Received: from [10.87.48.14] (unknown [86.42.25.131]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4559EBDF9; Thu, 16 Jan 2014 21:30:16 +0000 (GMT)
Message-ID: <52D84F68.7030100@cs.tcd.ie>
Date: Thu, 16 Jan 2014 21:30:16 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 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>
In-Reply-To: <20140116192320.GD32098@thunk.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Adrian Farrel <adrian@olddog.co.uk>, perpass <perpass@ietf.org>, Stephen Kent <kent@bbn.com>
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: Thu, 16 Jan 2014 21:30:34 -0000
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. 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. 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. And our draft is meant to be the same - another tool for the tool-box. (Well, assuming it turns out to be a useful tool, which is still not yet known.) Cheers, S.
- [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