Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt)
Phillip Hallam-Baker <hallam@gmail.com> Tue, 21 January 2014 16:05 UTC
Return-Path: <hallam@gmail.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 DA2BE1A0360 for <perpass@ietfa.amsl.com>; Tue, 21 Jan 2014 08:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 P_8fd4WrnjpM for <perpass@ietfa.amsl.com>; Tue, 21 Jan 2014 08:05:14 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 883FE1A0346 for <perpass@ietf.org>; Tue, 21 Jan 2014 08:05:14 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id w7so5611622lbi.35 for <perpass@ietf.org>; Tue, 21 Jan 2014 08:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c019JWwzMo8ptAKIo7sS13eu1/R9haK+M/1J2OhYkfI=; b=t+bkgWIEum9Xs9WyXJPkP4jCBnh0MOXgUC3cnL9P4d5figahQ8bhxChG7TufqZNw/O KYV2ggP0yJNOddHO0qiBkCfCa7GSFkuHwNmMDcmgnt6CHNhz14PmXd3NKNflQXoxI9bN 9kJp8KdqfnV9fi+MXCfTda4E3ZSUyUkaDIYnlbh4Q7Cwr/nmL18IhKCiSJv9fGt2Uox4 +U+9jOvAZLVIBEahf+Dec/fne2Eygs4qs02mKBS/lxxrOn9+fgwxG1k9xLEUFM6HZalS 5Iwd+jlaycw+7WuSn8wfE2BJfEUa1OynH/rmX/ZuTfts8CYP4ev8eBNFG1ikLODMUqg9 +72A==
MIME-Version: 1.0
X-Received: by 10.112.139.72 with SMTP id qw8mr15997798lbb.16.1390320313649; Tue, 21 Jan 2014 08:05:13 -0800 (PST)
Received: by 10.112.37.172 with HTTP; Tue, 21 Jan 2014 08:05:13 -0800 (PST)
In-Reply-To: <52DE9174.7000504@bbn.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>
Date: Tue, 21 Jan 2014 11:05:13 -0500
Message-ID: <CAMm+Lwiy-TTt-tShH3KkJ_u+L8JXtOLpwx1zmtTy7Rq9G977PQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="089e0112c1ba6b4fff04f07d2c47"
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:05:17 -0000
On Tue, Jan 21, 2014 at 10:25 AM, Stephen Kent <kent@bbn.com> wrote: > PHB, > ... > > >> One major design limit in IPSEC and TLS is that both view the key >> exchange as being integral to the security layer rather than a separate >> service. I would like to separate out consideration of how chunks of data >> passing over the net are tagged and bagged for encryption and >> authentication from the question of key setup. >> > IKE is separate from ESP and AH. ESP and AH can be used independently of > IKE, although manual keying > is obviously not attractive in most cases. TLS is a different matter, in > that the handshake that > puts keys in place is integral to the data security protocol. However, > DTLS is used with SRTP > to secure VoIP, showing that the key exchange there can be used to support > other protocols. > > >> There is no logical reason why the key negotiation for TLS, IPSEC and >> tcpcrypt cant be shared. >> > yes, it could be, despite the erroneous assertions above ;-) > Please do not confuse your misunderstanding of my post with my knowledge of the circumstances. 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. 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. 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. -- Website: http://hallambaker.com/
- [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