Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt)
Stephen Kent <kent@bbn.com> Tue, 21 January 2014 16:30 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 B6AC61A02ED for <perpass@ietfa.amsl.com>; Tue, 21 Jan 2014 08:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level:
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 anWa0KIqNn_J for <perpass@ietfa.amsl.com>; Tue, 21 Jan 2014 08:30:56 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FE1A017E for <perpass@ietf.org>; Tue, 21 Jan 2014 08:30:56 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:57933 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1W5eE3-0009Ss-WC; Tue, 21 Jan 2014 11:30:56 -0500
Message-ID: <52DEA0BF.3020507@bbn.com>
Date: Tue, 21 Jan 2014 11:30:55 -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: 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> <52DD3CAA.6010004@bbn.com> <52DD3E64.2000707@cs.tcd.ie> <52DD404B.1080705@bbiw.net> <CAMm+Lwh0Lm0NbTjAO0h4weUUQhi_oS230r6wxsE09Pc8enKoRw@mail.gmail.com> <52DE9174.7000504@bbn.com> <CAMm+Lwiy-TTt-tShH3KkJ_u+L8JXtOLpwx1zmtTy7Rq9G977PQ@mail.gmail.com>
In-Reply-To: <CAMm+Lwiy-TTt-tShH3KkJ_u+L8JXtOLpwx1zmtTy7Rq9G977PQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020608080008010105010101"
Cc: perpass <perpass@ietf.org>
Subject: Re: [perpass] tcpcrypt applicability (Was: Re: 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: Tue, 21 Jan 2014 16:30:59 -0000
PHB, ... > Please do not confuse your misunderstanding of my post with my > knowledge of the circumstances. read what I wrote, as opposed to your misunderstanding ... > IKE is certainly not currently packaged up for use an independent > service. Saying that this could be done is not the same as it having > been done. > The current IKE document begins as follows: > > Kaufman, et al. Standards Track [Page 4] > <http://tools.ietf.org/html/rfc5996#page-5> > RFC 5996 <http://tools.ietf.org/html/rfc5996> IKEv2bis September 2010 > > > 1 <http://tools.ietf.org/html/rfc5996#section-1>. Introduction > > > > > IP Security (IPsec) provides confidentiality, data integrity, access > control, and data source authentication to IP datagrams. I said that IKE is _separate_ from ESP and AH and that _AH and ESP can be used without IKE_. It is true that IKE is a version of ISAKMP that has been tailored to support IPsec, but it is still independent of ESP and AH; IKE uses its own mechanisms to protect its SAs, not ESP. > That is not how I expect a document describing an independent crypto > protocol designed for use in other schemes to begin. > > Suggesting that the IETF adopt a practice of requiring re-use of such > schemes in the security area is actually suggesting quite a major > change in our approach. i.e. instead of having PGP and S/MIME sit in > separate rooms defining two different message formats for secure > email, require them to agree on one message format that can be used > with both trust infrastructures. (O)PGP and S/MIME are different in more ways than the assumed "trust infrastructure." I think no one is requiring re-use of IKE in contexts where it is not appropriate. However, given the complexity of developing good key management protocols, Security ADs usually advise against creating a new one unless it is necessary. > The idea that key exchange can be implemented as an independent Web > Service is not something I expect to see in the IPSEC docs since the > originals were written several years before the term was coined. Ah, so your (previously hidden) agenda is a push for a Web Service for key management. Well, at least that's on the table now, sitting next to OmniBroker. 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