[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] [Fwd: [p2p-hackers] TODAY/URGENT: Stop IETF Enactmentof Patented Standard for TLS]
I guess I am being a little semantic, Allen, because all applications send messages, after all. :-). However, if "end-to-end security" means "application-to-application security" and if it makes business people understand that EKMI can give them "end-to-end security", then I'm all for it. Arshad Allen wrote: > 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=1845 >>>> >>> >>> >>> 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 >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]