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> Wed, 29 January 2014 19:35 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 CC1F51A0363 for <perpass@ietfa.amsl.com>; Wed, 29 Jan 2014 11:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.335
X-Spam-Level:
X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 kmLX0Z3GKu4T for <perpass@ietfa.amsl.com>; Wed, 29 Jan 2014 11:35:03 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8A1A0240 for <perpass@ietf.org>; Wed, 29 Jan 2014 11:35:03 -0800 (PST)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53773) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1W8aua-000A8H-AE for perpass@ietf.org; Wed, 29 Jan 2014 14:35:00 -0500
Message-ID: <52E957E4.4000303@bbn.com>
Date: Wed, 29 Jan 2014 14:35:00 -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: perpass@ietf.org
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> <52DEA0BF.3020507@bbn.com> <CAMm+LwiwssLsqkQH35LRsCP4Eo-7qB8y0t6W2T8XuMBx6mtUeA@mail.gmail.com> <52DFDA03.3060608@bbn.com> <CAMm+Lwg5cnF4PJHnNbui35FRX=X=R_Dw8+1DWMDCQLS61iQACw@mail.gmail.com>
In-Reply-To: <CAMm+Lwg5cnF4PJHnNbui35FRX=X=R_Dw8+1DWMDCQLS61iQACw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090301030805030904000703"
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: Wed, 29 Jan 2014 19:35:14 -0000
On 1/22/14 11:40 AM, Phillip Hallam-Baker wrote: > I find it rather interesting that someone who takes great offense when > it is pointed out that he works under contract to the NSA goes after > people for having a 'hidden' agenda. > > If you want to start questioning people's ulterior or bought motives > you are sawing off a mighty fine branch there and its the one you are > standing on. > > Is the reason that you are arguing against Omnibroker so hard because > someone in Fort Meade is getting nervous? Maybe they should, they had > three people come to see my first public talk on PRISM-PROOF email. Or > is it impolite for me to ask such questions because you are the only > person allowed to call people's motives into question? PHB, I'm pretty sure communism didn't enter into my comments on your proposals :-). I also have no idea whether anyone at NSA has any interest in Omnibroker. To the extent that it represents an opportunity for centralizing and outsourcing trust services, I can imagine some there might even find it attractive :-). I have absolutely no desire to watch any YouTube videos you have produced. I'd like to think that, during over 30 years of participation in Internet standards, my agenda has never been hidden. Yes, I am a government contractor. I have received funding from various parts of the DoD (including DARPA, DCA, Army, Navy, etc.) the DHS, and otherorganizations. In most cases, and for all of my recent funding (say, over the past 20ish years) the work I do is the result of what I have proposed to funding organizations, because I think it is useful for improving Internet security. I don't tend to bid on BAAs or RFPs from funding agencies; instead, I approach them, describe security problems I think are important and where I think I can help, and ask for money to do the work. Sometimes I get funds, sometimes not. But my agenda is overt. Sometimes IETF participants have asked why I participate in the IETF, since I am do not work for a product company or a service provider, and I've explained, as above. For example, my work on IPsec was motivated by years of experience with layer 3 security technology. When I began working at BBN, in the later 70's, we had an ARPA (now DARPA) project to build the first packet network encryption system, using a KDC. I worked on that project, extending the architecture to accommodate multiple KDCs (for robustness) and to enable establishing security associations across administrative domains. The hardware we used (inline hardware crypto, built by another government contractor) employed the first DES chips certified by NBS (now NIST). BBN wrote the software, which worked with early versions of TCP and IP. This work was completed, including performance testing, several years before MIT initiated Project Athena, and developed Kerberos. In the latter 80's and early 90's I was a participant in the SDNS (Secure Data Network Systems) program (which was sponsored by NSA) to develop network layer crypto systems for protecting DoD classified data. That program developed SP3, a precursor to IPsec, and MSP, some aspects of which appear in S/MIME. The MSP work leveraged my experience leading work on PEM, the first e-mail Internet standard security protocol. (PEM was initially developed initially in the Privacy and Security Research Group, then in the PEM WG, both of which I chaired.) This showed that DoD-sponsored work canbenefit from work performed in the "outside" world. In the late 90's and through 2005, I contributed to, and eventually became responsible for, the IPsec RFCs, bringing to that effort some of the experience I gained in the SDNS program. (BTW, all of the SDNS protocol specs were unclassified, because NSA wanted vendors to use them in buildingsystems to protect unclassified, as well as classified, data.) So, in this case, experience flowed from government work to the public standards sector. At one time NSA bought into what the big telecom providers were saying, and created network layer crypto that worked only with ATM. This was brought to my attention by a router vendor, who was hoping to sell products to DoD clients, who could not use the routers because they were not compatible with the latest, fastest crypto available for protecting classified data. When I because aware of this I urged NSA to revisit IP-based network crypto. They had been told that IP-based crypto systems would be slow, compared to the ATM-based systems they were fielding. So, some colleagues at BBN and I designed a 10Gb/s IP crypto device (that used DoD algorithms approved to protect classified data), to demonstrate that IP crypto could be fast. That effort (yes, we were paid!) led to a significant program change, so that when ATM stopped being the "next big thing" and fast IP routers were available, there were network layer crypto devices that would work with them. The resulting products were called HAIPEs (High Assurance IP Encryptors). I wasn't pleased with all aspects of those products, but at least we avoided the ATM dead end J. I chaired PKIX for about 18 years; part of the funding for my participation came from the DoD. They were making a big investment in PKI and were willing to help support work that advanced PKI standards. They became a big user of OCSP (not my personal, favorite protocol, but ...) and thus benefitted from the existence of an IETF WG that offered a forum for developing PKI standards. My co-chairs over this time included folks from the PKI industry, NIST, and Microsoft. Since the last 90's I have worked on architectures to improve inter-domain routing security. This work was sponsored initially by DARPA, and later received DHS funds, in part because the principal sponsor moved from DARPA to DHS! My work in SIDR, on the RPKI and BGPSEC, has been paid for by DHS and DoD, because they see the need for better routing security. Nothing mysterious there. Overall, I am pretty proud of the work I have done in the IETF, the 22 (soon to be 23) RFCs that I've published, my time on the IAB, chairing the PSRG, PEM and PKIX WGs, serving on four Nomcoms, and my contributions to other WGs. In all of the years that I have worked on Internet standards the only RFC that recall writing in response to a request from the DoD was my first, RFC 1108. That RFC (published in 1991) described the IPv4 basic and extended security options, as implemented in a DoD network crypto system (BLACKER) of the 80's. I don't think that work, or anything I have done since, makes me an agent provocateur. 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