[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ekmi] [Fwd: [p2p-hackers] TODAY/URGENT: Stop IETF Enactment of Patented Standard for TLS]
Here's the press release from Heartland: http://www.snl.com/irweblinkx/file.aspx?IID=4094417&FID=7261934 In all fairness, they didn't say end-to-end security, but did say end-to-end encryption. I think the plan that they are going to try to implement is admirable, but I fear that they are not considering the impact of encrypting data is going to have. It's very possible that once they are done with the changes that are necessary to encrypt data in the card transaction process they will end up with an unmanageable key environment. -Marc -----Original Message----- From: Allen [mailto:netsecurity@sound-by-design.com] Sent: Wednesday, February 11, 2009 2:40 PM To: Arshad Noor Cc: ekmi Subject: Re: [ekmi] [Fwd: [p2p-hackers] TODAY/URGENT: Stop IETF Enactment of Patented Standard for TLS] Hi Arshad, Yes, you are correct about "message-level security;" however, that is not a good term to use as it implies that it is about messages rather than data security. A better term, although a bit ambiguous, is "end-to-end security." This is the term that is beginning to be used more and more recently. I saw a press release where Heartland Payment Systems, the recent credit card processor breach victim, is saying that the only real choice is end-to-end security and they are going to adopt it. Here is another little tidbit that is relevant to them and data security: > "By the latest count, the number of institutions that have informed their card customers and members that they were hit as a result of the Heartland Payment Systems (HPY) data breach has swelled to 157. > > Heartland, the sixth-largest payments processor in the U.S., announced on Jan. 20 that its processing systems were breached in 2008, exposing an undetermined number of consumers to potential fraud. Since then, scores of banks and credit unions from across North America have stepped forward to say their customers are among those whose cards were compromised in the breach." > > http://www.bankinfosecurity.com/articles.php?art_id=1200&rf=021109eb Maybe we could think of a better term that is more descriptive of what we are promoting. What do people think of "end-to-end data security?" Getting the right term is often the best way to get adoption as people understand it from the beginning and it feels comfortable. Best, Allen Arshad Noor wrote: > Allen, > > Thanks for forwarding this. I wish I had time to read the IETF DRAFT > before forming an opinion on this, but I don't. > > However, I wouldn't feel too bad even if this proprietary technology > made it into an RFC standard. The market has gotten smarter in the > last 10 years and will not be so accepting of technologies if people > don't see a clear benefit over professional open-source. > > One advantage of SKSML we all haven't discussed is the notion that it > promotes "message-level security", which has a huge-advantage over > TLS, SSL and IPSec: that it is secure all the way upto the application > layer. Given the kinds of breaches we're seeing professional attackers > performing, network-level security is about as useful as a firewall - > necessary as a baseline just in case you forgot something, but hardly > a defense-mechanism that allows you to sleep at night. > > IMHO, the new breed of secure applications will rely only on "message- > level security", since this allows the payload to be secure on the > network, on the disk, in caches, in the middleware - anywhere, except > where the application chooses to use it in plaintext. > > Arshad > > Allen wrote: >> I think this might merit the attention of the people of the EKMI TC. >> Although it is not directly related to EKMI, it does show the >> potential threat to open source that needs to be addressed by all who >> value it. If one company can manage to push through a "proposed >> standard" and then threaten to sue if it is used, it puts all open >> source projects at risk of having to "prove" prior art or that the >> company is being over broad in its claims. >> >> In a way this parallels the Unix suits that have eaten a lot of money >> and energy. We must not let this happen again, if possible. >> >> Thanks for you time and attention. >> >> Warmest Regards, >> >> Allen Schaaf - CISSP, CEH, CHFI, CEI >> Information Security Analyst - Business Process Analyst >> Training & Instructional Designer - Sr. Writer & Documentation >> Developer - Certified Network Security Analyst & Intrusion >> Forensics Investigator - Certified EC-Council Instructor >> http://www.linkedin.com/in/allenschaaf >> >> Security is lot like democracy - everyone's for it but >> few understand that you have to work at it constantly. >> >> >> >> -------- Original Message -------- >> Subject: [p2p-hackers] TODAY/URGENT: Stop IETF Enactment of >> Patented Standard for TLS >> Date: Wed, 11 Feb 2009 07:38:15 -0500 >> From: Seth Johnson <seth.johnson@RealMeasures.dyndns.org> >> Reply-To: seth.johnson@RealMeasures.dyndns.org, theory and practice >> of decentralized computer networks <p2p-hackers@lists.zooko.com> >> Organization: Real Measures >> To: p2p-hackers@lists.zooko.com, decentralization@yahoogroups.com >> References: <48804AEE.2231AA61@RealMeasures.dyndns.org> >> <49524E6F.BB09B1C4@RealMeasures.dyndns.org> >> >> >> (Urgent. Send your note TODAY and CONFIRM the automatic reply from >> IETF. You can cc campaigns@fsf.org . Three links below, FSF's action >> page, Glyn Moody's blog, and the list announcement for TLS-AUTHZ at >> IETF. -- Seth) >> >> >>> http://www.fsf.org/news/reoppose-tls-authz-standard >> >> >> Send comments opposing TLS-authz standard by February 11 >> >> >> Last January, the Free Software Foundation issued an alert to efforts >> at the Internet Engineering Task Force (IETF) to sneak a >> patent-encumbered standard for "TLS authorization" through a back-door >> approval process that was referenced as "experimental" or >> "informational" >> (http://www.fsf.org/news/reoppose-tls-authz-standard/newsitem_view). >> The many comments sent to IETF at that time alerted committee members >> to this attempt and successfully prevented the standard gaining >> approval. >> >> Unfortunately, attempts to push through this standard have been >> renewed and become more of a threat. The proposal now at the IETF has >> a changed status from "experimental" to "proposed standard". The FSF >> is again issuing an alert and request for comments to be sent urgently >> and prior to the February 11 deadline to ietf@ietf.org. Please >> include us in your message by a CC to campaigns@fsf.org. You should >> also expect an automated reply from ietf@ietf.org, which you will need >> to answer to confirm your original message. >> >> That patent in question is claimed by RedPhone Security >> (https://datatracker.ietf.org/ipr/1026/). RedPhone has given a >> license to anyone who implements the protocol, but they still threaten >> to sue anyone that uses it. >> >> If our voice is strong enough, the IETF will not approve this standard >> on any level unless the patent threat is removed entirely with a >> royalty-free license for all users. >> >> Further background for your comment >> >> See the IETF summary: >>> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html >> >> Much of the communication on the Internet happens between computers >> according to standards that define common languages. If we are going >> to live in a free world using free software, our software must be >> allowed to speak these languages. >> >> Unfortunately, discussions about possible new standards are tempting >> opportunities for people who would prefer to profit by extending >> proprietary control over our communities. If someone holds a software >> patent on a technique that a programmer or user has to use in order to >> make use of a standard, then no one is free without getting permission >> from and paying the patent holder >> (http://www.gnu.org/philosophy/fighting-software-patents.html). If we >> are not careful, standards can become major barriers to computer users >> having and exercising their freedom. >> >> We depend on organizations like the Internet Engineering Task Force >> (IETF) and the Internet Engineering Steering Group (IESG) to evaluate >> new proposals for standards and make sure that they are not encumbered >> by patents or any other sort of restriction that would prevent free >> software users and programmers from participating in the world they >> define. >> >> In February 2006, a standard for "TLS authorization" was introduced in >> the IETF for consideration >> (http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt). >> Very late in the discussion, a company called RedPhone Security >> disclosed (this disclosure has subsequently been unpublished from the >> IETF website) that they applied for a patent which would need to be >> licensed to anyone wanting to practice the standard >> (https://datatracker.ietf.org/ipr/833/). After this disclosure, the >> proposal was rejected. >> >> Despite claims that RedPhone have offered a license for implementation >> of this protocol, users of this protocol would still be threatened by >> the patent. The IETF should continue to oppose this standard until >> RedPhone provide a royalty-free license for all users. >> >> Media Contacts >> >> Peter T. Brown >> Executive Director >> Free Software Foundation >> (617)542-5942 >> campaigns@fsf.org >> >> --- >> >>> http://www.computerworlduk.com/community/blogs/index.cfm?blogid=14&entryid=1 845 >>> >> >> >> Help Fight This Patent-Encumbered IETF Standard >> >> February 10, 2009 >> >> Posted by: Glyn Moody >> >> I've written numerous times about the importance of writing to >> governments about their hare-brained schemes, but this one is rather >> different. In this case, it's the normally sane Internet Engineering >> Task Force that wants to do something really daft. The FSF explains: >> >> Last January, the Free Software Foundation issued an alert to efforts >> at the Internet Engineering Task Force (IETF) to sneak a >> patent-encumbered standard for "TLS authorization" through a back-door >> approval process that was referenced as "experimental" or >> "informational". The many comments sent to IETF at that time alerted >> committee members to this attempt and successfully prevented the >> standard gaining approval. >> >> Unfortunately, attempts to push through this standard have been >> renewed and become more of a threat. The proposal now at the IETF has >> a changed status from "experimental" to "proposed standard". >> >> This is a throwback to the bad old days of sneaking patents into >> nominal standards. It is yet another reason why such patents should >> not be given in the first place. But until such time as the patent >> offices around the world come to their senses, the only option is to >> fight patent-encumbered standards on an individual basis. Here are the >> details for doing so: >> >> The FSF is again issuing an alert and request for comments to be sent >> urgently and prior to the February 11 deadline to ietf@ietf.org. >> Please include us in your message by a CC to campaigns@fsf.org. You >> should also expect an automated reply from ietf@ietf.org, which you >> will need to answer to confirm your original message. >> >> Here's what I've sent: >> >> I am writing to ask you not to approve the proposed patent-encumbered >> standard for TLS authorisation. To do so would fly in the face of the >> IETF's fundamental commitment to openness. It would weaken not just >> the standard itself, but the IETF's authority in this sphere. >> >> --- >> >>> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html >> >> >> Fourth Last Call: draft-housley-tls-authz-extns >> >> * To: IETF-Announce <ietf-announce at ietf.org> >> * Subject: Fourth Last Call: draft-housley-tls-authz-extns >> * From: The IESG <iesg-secretary at ietf.org> >> * Date: Wed, 14 Jan 2009 08:18:20 -0800 (PST) >> * List-archive: <http://www.ietf.org/pipermail/ietf-announce> >> * Reply-to: ietf at ietf.org >> >> >> On June 27, 2006, the IESG approved "Transport Layer Security (TLS) >> Authorization Extensions," (draft-housley-tls-authz-extns) as a >> proposed standard. On November 29, 2006, Redphone Security (with whom >> Mark Brown, a co-author of the draft is affiliated) filed IETF IPR >> disclosure 767. >> >> Because of the timing of the IPR Disclosure, the IESG withdrew its >> approval of draft-housley-tls-authz-extns. A second IETF Last Call >> was initiated to determine whether the IETF community still had >> consensus to publish draft-housley-tls-authz-extns as a proposed >> standard given the IPR claimed. Consensus to publish as a standards >> track document was not demonstrated, and the document was withdrawn >> from IESG consideration. >> >> A third IETF Last Call was initiated to determine whether the IETF >> community had consensus to publish draft-housley-tls-authz-extns as an >> experimental track RFC with knowledge of the IPR disclosure from >> Redphone Security. Consensus to publish as experimental was not >> demonstrated; a substantial segment of the community objected to >> publication on any track in light of the IPR terms. >> >> Since the third Last Call, RedPhone Security filed IETF IPR disclosure >> 1026. This disclosure statement asserts in part that "the techniques >> for sending and receiving authorizations defined in TLS Authorizations >> Extensions (version draft-housley-tls-authz-extns-07.txt) do not >> infringe upon RedPhone Security's intellectual property rights". The >> full text of IPR disclosure 1026 is available at: >> >> https://datatracker.ietf.org/ipr/1026/ >> >> This Last Call is intended to determine whether the IETF community had >> consensus to publish draft-housley-tls-authz-extns as a proposed >> standard given IPR Disclosure 1026. >> >> The IESG is considering approving this draft as a standards track RFC. >> The IESG solicits final comments on whether the IETF community has >> consensus to publish draft-housley-tls-authz-extns as a proposed >> standard. Comments can be sent to ietf at ietf.org or exceptionally to >> iesg at ietf.org. Comments should be sent by 2009-02-11. >> >> A URL of this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php No virus found in this incoming message. Checked by AVG. Version: 7.5.552 / Virus Database: 270.10.22/1946 - Release Date: 2/11/2009 11:13 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.552 / Virus Database: 270.10.22/1946 - Release Date: 2/11/2009 11:13 AM
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]