Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/27/2010 12:38 AM, Richard Salz wrote: (For what it's worth, I find your style of monocase and ellipses so incredibly difficult to read that I usually delete your postings unread.) It is well studied. I had gotten blamed for online computer conferencing on the internal network in the late 70s and early 80s (rumor is that when the executive committee became aware ... 5of6 wanted to immediately fire me ... supposedly there was only one holdout). somewhat as a result, there was a researcher paid to sit in the back of my office for nine months, taking notes on how I communicated, face-to-face, telephone, computer ... got copies of all incoming and outgoing email, logs of all instant messages, etc. Besides being a corporate research report, it was also the basis for several papers, books and stanford phd (joint between language and computer AI). One number was that I avg. electronic communication with 275 different people per week for the 9month period. lots of past posts mentioning computer mediated communication http://www.garlic.com/~lynn/subnetwork.html#cmc in any case, we were brought in to help wordsmith the cal. state electronic signature legislation. the certification authority industry was heavily lobbying (effectively) that digital certificates had to be mandated for every adult. The certification authority industry, besides doing the SSL domain name digital certificates were out pitching to wall street money people a $20B/annum business case (basically all adults with $100/annum digital certificate). Initially they appeared to believe that the financial industry would underwrite the certificates. The financial industry couldn't see the justification for the $20B/annum transfer of wealth to the certification authentication industry. There were various attempts then to convince consumers that they should pay it directly out of their own pocket. in payment area, they were also pitching to the merchants that part of deploying digital certificates infrastructure, the burden of proof in digitally signed payment transactions, would be switched to consumers (somewhat like UK where approx. that has happened as part of payment hardware tokens). That netted out to consumers paying $100/annum (for digital certificates), out of their own pocket, for the privilege of having the burden of proof in disputes shifted to them. that didn't sell ... so there was heavy lobbying all around the world wanting gov mandating digital certificates for every adult (payed for by the individual). The lawyers working on the cal. legislation explained why digital signatures didn't meet the criteria for "human signatures" (demonstration of human having read, agreed, authorizes, and/or approved) needed by electronic signature legislation. we got some patents in the area, the 32nd just granted on tuesday, they are all assigned, we have no interest and have been long gone for years. There are a couple issues with new technology uptake ... much more successful when 1) there is no incumbent technology already in the niche and 2) there are strong champions with profit motivation and 3) there is at least some perceived benefit. In the 90s, I would pontificate how SSL domain name certificates didn't actually provide any significant security ... but were "comfort" certificates (for consumers), aka benefit was significantly a matter of publicity. Better solutions that come along later don't necessarily win ... having incumbent to deal with and are especially at a disadvantage if there aren't major champions (typically with strong profit motivation). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
(For what it's worth, I find your style of monocase and ellipses so incredibly difficult to read that I usually delete your postings unread.) > as previously mentioned, somewhere back behind everything else ... there > is strong financial motivation in the sale of the SSL domain name digital > certificates. I don't doubt that this was true when it was the secure sockets layer and "e-commerce on the web" were just starting up. But I don't think it's accurate any longer. Or rather, who cares how VRSN wants to make money? :) Verisign owns a large portion of the CA market; their market-cap is US$5B. Google's is US$143B, Apple's is US$220B and Microsoft's is US$206B. I mention Google because they are very involved and influential in Internet infrastructure, and Apple because many believe they will be dominant content delivery system, and Microsoft because they were a sponsor of the original SDSI research ( http://people.csail.mit.edu/rivest/sdsi10.html) If someone has a better mousetrap, there's several places that can make it happen and swallow 44% of the SSL market ( https://press.verisign.com/easyir/customrel.do?easyirid=AFC0FF0DB5C560D3&version=live&prid=631314&releasejsp=custom_97 ) with nary a burp. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
Richard Salz writes: > A really knowledgeable net-head told me the other day that the problem > with SSL/TLS is that it has too many round-trips. In fact, the RTT costs > are now more prohibitive than the crypto costs. I was quite surprised to > hear this; he was stunned to find it out. Cryptographic operations are measured in cycles (i.e. nanoseconds now); network operations are measured in milliseconds. That should not be a stunning surprise. What is neither stunning nor surprising, but continually sad, is that web developers don't measure anything. Predictably, web app performance is unnecessarily terrible. I once asked some developers why they couldn't use HTTPS. "Performance!" was the cry. "Ok," I said. "What is your performance target, and by how much does HTTPS make you miss it? Maybe we can optimize something so you can afford HTTPS again." "As fast as possible!!!" was the response. When I pointed out that their app sent AJAX requests and responses that were tens or even hundreds of KB every couple seconds, and that as a result their app was barely usable outside their LAN, I was met with blank stares. Did they use HTTP persistent connections, TLS session resumption, text content compression, maximize HTTP caching, ...? I think you can guess. :) Efforts like SPDY are the natural progression of organizations like Google *WHO HAVE ALREADY OPTIMIZED EVERYTHING ELSE*. Until you've optimized the content and application layers, worrying about the transport layers makes no sense. A bloated app will still be slow when transported over SPDY. Developers are already under the dangerous misapprehension that "TLS is too expensive". When they hear security experts and cryptographers mistakenly agree, the idea will stick in their minds forever; we will have failed. The problem comes from insufficiently broad understanding: the sysadmins fiddle their kernel tuning knobs, the security people don't understand how applications work, and the developers call malloc 5,000 times and perform 2,500 I/O ops just to print "Hello, World". The resulting software is unsafe, slow, and too expensive. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Thu, 26 Aug 2010, d...@geer.org wrote: > as previously mentioned, somewhere back behind everything else ... there > is strong financial motivation in the sale of the SSL domain name digital > certificates. > While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. Currently, the IETF keyassure WG is working on specifying how to use DNS(SEC) to put the certs in the DNS to avoid the entire CA authentication. It seems to be deciding on certs (not raw keys/hashes) to simplify and re-use the existing TLS based implementations (eg HTTPS) Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/26/2010 06:38 AM, d...@geer.org wrote: While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. the profit from sale of SSL domain name certs had profit motivation pretty much unrelated to the overall costs to the infrastructure ... and so there was an extremely strong champion. simply enhancing DNS and doing real-time trusted public key distribution thru a trusted domain name infrastructure ... was all cost with no champion with strong profit motivation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 25/08/10 11:04 PM, Richard Salz wrote: A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Yes, it is inherent in the design assumptions of the early 1990s. At the time, the idea was to secure HTTP, which was (is) a request-response protocol layered over TCP. Now, some of the design features that the designers settled on were: + ignore HTTP and secure TCP + make SSL look just like TCP + third-party authority authentication + no client-side caching of certs And those features they delivered reasonably well. However, if they had dug a bit deeper at the time (unlikely, really unlikely) they would have discovered that the core HTTP protocol is request-response, which means it is two packets, one for request and one for response. Layering HTTP over TCP was a simplification, because just about everyone does that, and still does it for whatever reason. However it was a simplification that ultimately caused a lot more cost than they realised, because it led to further layering, and further unreliability. The original assumptions can be challenged. If one goes to pure request-respose, then the whole lot can be done over datagrams (UDP). Once that is done properly, the protocol can move to 4 packets startup, then cached 2 packets mode. The improvement in reliability is a gift. This is possible, but you have to think outside the box, discard the obsession of layering and the mindtrap of reliable TCP. I've done it, so I know it's possible. Fast, and reliable, too. Lynn as well, it seems. James points out the architectural secret, that security has to be baked into the app, any security below the app is unreliable. Look at the "tlsnextprotonec" IETF draft, the Google involvement in SPDY, SPDY only takes the low-hanging fruit, IIRC. Very cautious, very conservative, hardly seems worth the effort to me. and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. If you're content with slow, stick with TLS :) Fast starts with a clean sheet of paper. It is of course a complete rewrite, but IMHO the work effort is less than working with layered mistakes of the past. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
> > as previously mentioned, somewhere back behind everything else ... there > is strong financial motivation in the sale of the SSL domain name digital > certificates. > While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
> A really knowledgeable net-head told me the other day that the problem > with SSL/TLS is that it has too many round-trips. In fact, the RTT costs > are now more prohibitive than the crypto costs. Yes, although that's a different class of issue from the ones we're trying to address in hasmat and keyassure. these two drafts comprise the approach Adam Langley (of google) is presently pursuing wrt both fast TLS startup (snapstart) and support for NextProtocolNegotiation (during TLS handshake).. http://tools.ietf.org/html/draft-agl-tls-nextprotoneg http://tools.ietf.org/html/draft-agl-tls-snapstart Note that the motivation for draft-agl-tls-nextprotoneg is so-called websockets, which are being worked on in the IETF HYBI (hypertext bidirectional) WG http://datatracker.ietf.org/wg/hybi/ =JeffH - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/25/2010 09:04 AM, Richard Salz wrote: Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic "STS" policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Look at the "tlsnextprotonec" IETF draft, the Google involvement in SPDY, and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. the work on HSP (high-speed protocol) in the late 80s was to do reliable transmission in minimum 3-packet exchange; compared to 5-packet minimum for VMTP (rfc1045) and 7-packet minimum for tcp (disclaimer, i was on related technical advisory board for HSP ... while at IBM ... over strong objections from the communication division; but that also strong protested that we had come up with 3-tier architecture and were out pitching it to customer executives ... at a time when they were attempting to get the client/server genie back into the terminal emulation bottle) then SSL theoretically being stateless on top of tcp added a whole bunch of additional chatter. there has frequently between changing trade-offs between transmission and processing ... but SSL started out being excessive in both transmission and processing (in addition to having deployment requirement that the user understand the relationship between the website they believed they were talking to and the URL they had to supply to the browser a requirement that was almost immediately violated). my pitch forever has been to leverage key distribution piggy-backed on domain name to ip-address (dns) response ... and use that to do encrypted/validated reliable transaction within HSP 3-packet minimum exchange. as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Aug 25, 2010, at 9:04 20AM, Richard Salz wrote: >> Also, note that HSTS is presently specific to HTTP. One could imagine >> expressing a more generic "STS" policy for an entire site > > A really knowledgeable net-head told me the other day that the problem > with SSL/TLS is that it has too many round-trips. In fact, the RTT costs > are now more prohibitive than the crypto costs. I was quite surprised to > hear this; he was stunned to find it out. This statement is quite correct. I know of at least one major player that was very reluctant to use SSL because of this issue; the round trips, especially on intercontinental connections, led to considerable latency, which in turn hurt the perceived responsiveness of their service. We need to do something about the speed of light. Is anyone working on hyperwave or subether technologies? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
> Also, note that HSTS is presently specific to HTTP. One could imagine > expressing a more generic "STS" policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Look at the "tlsnextprotonec" IETF draft, the Google involvement in SPDY, and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Sun, Aug 22, 2010 at 11:51:01AM -0400, Anne & Lynn Wheeler wrote: > On 08/22/2010 06:56 AM, Jakob Schlyter wrote: > >There are a lot of work going on in this area, including how to use secure > >DNS to > >associate the key that appears in a TLS server's certificate with the the > >intended > >domain name [1]. Adding HSTS to this mix does make sense and is something > >that is > >discussed, e.g. on the keyassure mailing list [2]. > > There is large vested interested in Certification Authority industry > selling SSL domain name certificates. A secure DNS scenario is having > a public key registered at the time the domain name is registered ... > and then a different kind of TLS ... where the public key is returned > in piggy-back with the domain name to ip-address mapping response. for the conservative - they may want to verify the DNSSEC trust chains for both the domain name and the IP address. e.g. is it the same EV cert at the end of both validation checks. --bill - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/22/2010 06:56 AM, Jakob Schlyter wrote: There are a lot of work going on in this area, including how to use secure DNS to associate the key that appears in a TLS server's certificate with the the intended domain name [1]. Adding HSTS to this mix does make sense and is something that is discussed, e.g. on the keyassure mailing list [2]. There is large vested interested in Certification Authority industry selling SSL domain name certificates. A secure DNS scenario is having a public key registered at the time the domain name is registered ... and then a different kind of TLS ... where the public key is returned in piggy-back with the domain name to ip-address mapping response. This doesn't have the revenue infrastructure add-on that happened with the Certifcation Authority ... just is bundled as part of the existing DNS infrastructure. I've pontificated for years that it is catch-22 for the Certification Authority industry ... since there are aspects of improving the integrity of the DNS infrastructure i.e. Certification Authority industry is dependent on DNS ... aka The Certification Authority industry has to match the information from the SSL digital certificate applicant with the true owner of the domain name on file with the DNS infrastructure (among other things, requiring digitally signed communication that is authenticated with the onfile public key in the domain name infrastructure is a countermeasure to domain name hijacking ... which then cascades down the trust chain to hijackers applying for valid SSL domain name certificates). At 50k foot level, SSL domain name certificates were countermeasures to various perceived shortcomings in DNS integrity ... nearly any kind of improvements in DNS integrity contributes to reducing the motivation for SSL domain name certificates. Significantly improving integrity of DNS would eliminate all motivation for SSL domain name certificates. This would then adversely affect the revenue flow for the Certification Authority industry. I've also periodically claimed that OCSP appeared to be a (very rube-goldberg) response to my position that digital certificates (appended to every payment transaction) would actually set the state-of-the-art back 30-40 yrs (as opposed to their claims that appended digital certificates would bring payments into the modern era ... that was separate from the issue of the redundant and superfluous digital certificates representing a factor of 100 times payment transaction payload and processing bloat). Anything that appears to eliminate competition for paid-for SSL digital certificates and/or strengthen the position of Certification Authorities ... might be construed as having an industry profit motivation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
There are a lot of work going on in this area, including how to use secure DNS to associate the key that appears in a TLS server's certificate with the the intended domain name [1]. Adding HSTS to this mix does make sense and is something that is discussed, e.g. on the keyassure mailing list [2]. jakob [1] http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-00 [2] http://www.ietf.org/mailman/listinfo/keyassure - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
I read through the HTTP Strict Transport Security (HSTS) Draft RFC (http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02 ) and it's an odd mix. It continues - and expands on - Firefox's war against self-signed certs - while adding to the Web exactly the same kind of SSH-style "connection continuity" security for which self- signed certs are completely appropriate! Consider the scenarios: 1. "First connection" to an HSTS server. Here "first connection" means that client is approaching this server with no pre-existing security context - either it's never connected before, or it's stored no information that will influence security decisions on its part, from the previous connections, if any. Today, that describes *all* standard connections, though many different extensions have been proposed, and plug-ins implemented, to change this. The security of such a connection, in the presence of a MITM attack, depends entirely on the trustworthiness of the certificate chain. There is, ex hypothesi, nothing else that drives the client's decisions. HSTS has absolutely nothing to offer here. A MITM won't forward the HSTS information if it finds it inconvenient to do so. Or it will fake it. Because HSTS forbids self-signed certs, no legitimate server will present a combination of a self-signed cert and an HSTS header. No intelligent MITM will do so either. It will either suppress the HSTS header - or, more likely, use a perfectly legitimate cert signed by a perfectly legitimate CA that the client will accept. After all, there are hundreds of CA's out there and getting a signed cert is no big deal. HSTS *does* provide protection against a *passive* "first connection" attacker by blocking insecure connection attempts and requiring HTTPS. (Of course, you can do that in a server today with a redirect - and in fact that's exactly how HSTS does it.) 2. A "second connection": One where the client has retained information from a previous connection. HSTS adds this state to the standards: For an amount of time specified by the server on the previous connection, a new connection to the server (well, to be more careful, to the URI or possibly subdomains - the whole question of whether we are talking about a server or a URI or an address gets very complex if you try to pin it down exactly) must use HTTPS, and must get a "clean" connection, with no warnings (e.g., the CRL must be checkable) and no self-signed certs. So what does HSTS actually add? I'd say three things: - Standardization of, and requirement for, HTTP to HTTPS redirects; - Standardization of, and requirement for, clients to retain security information about previous connections, per server/URI/domain; - The notion of a "time to live" for that security information, set by the server. But having gone this far ... the proposal then goes off into the weeds by regulating self-signed certs for no really good reason, while ignoring much more valuable things it *could* do. There's nothing we can do about the MITM vulnerabilities in the first connection scenario without solving the PKI problem - which ain't gonna happen. (HSTS discusses the notion of pre-loading HSTS security information for some sites along with CA lists, but itself notes that this doesn't really solve any problems so much as rename them. Besides - once you start on this route, why not just distribute actual site keys?) But why not let the server say "On subsequent connections, only accept a cert with this fingerprint" (SSH connection) or "only accept a cert signed by this CA" (sites don't change CA's often, and the time limit means they can do so as long as they plan ahead) or "only accept certs signed by CA's based in the following country" (like Soghoian and Stamm's work). Why a "require this CA" together with a self-signed cert shouldn't be allowed is beyond me - I can't see any situation in which it's weaker than the current HSTS proposal. Now, it's quite true that HSTS *allows* for extensions - but so does HTTP, and so browsers. What's hard is to get something very broadly implemented. Having the "something" be HSTS would be squandering an opportunity. I certainly wouldn't try to include every, or even many, possibilities - that's a way of making sure that nothing gets done. By being able to say: For any connections to this server/URI/set of domains for the next n seconds, accept only HTTPS connections with certs signed by the following CA's (*including* self-signed certs!) - now, that would be useful. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
fyi, this is a heads-up about on-going work in this area... pgut...@cs.auckland.ac.nz wondered: > I noticed that Bank of America ... now finally use HTTPS on their home > page, and redirect HTTP to HTTPS ... Wachovia now do it too. And Citibank > at least redirect you to an HTTPS page. And so does US Bank ... > What on earth happened? Was there a change in banking regulations in > the last few months? fu...@yuggoth.org replied: > > On Fri, Aug 13, 2010 at 09:32:57AM -0700, Jeff Simmons noted: > >> It wouldn't surprise me if there's been some blowback from the >> adoption of PCI-DSS (Payment Card Industry Data Security >> Standards). As someone who has had to help several small to medium >> size businesses comply with these 'voluntary' standards, the irony >> of the fact that the big banks that require them often aren't in >> compliance themselves hasn't escaped my notice. > > In the past month, we've had several customers at work suddenly insist that > we make modifications to their firewalls and/or load balancers to redirect > *all* incoming HTTP traffic to HTTPS (which of course isn't always entirely > sane to do on proxying devices, but they apparently don't trust their server > admins to maintain an HTTP redirect). Most of them cited requirements from > their PCI-DSS auditors. ... Coincidentally with this apparent PCI-induced trickle-down of default employment of HTTPS, there's been relatively recent work on enabling web sites' declaration of security policies, and browser-side enforment of such. Presently there's a patchwork quilt of approaches, two in particular are directly on-topic with the spirit of the above questions and observations... EFF's HTTPS Everywhere (Peter Eckersley et al) https://www.eff.org/https-everywhere/ HTTP Strict Transport Security (HSTS) http://en.wikipedia.org/wiki/Strict_Transport_Security WRT the latter, we're forming a new IETF WG where it'll be finalized, along with a couple of other I-Ds (which are related patches in the quilt).. HASMAT Charter Proposal http://www.ietf.org/mail-archive/web/hasmat/current/msg6.html Not-coincidentally, the W3C is working towards establishing a web app security working group, where the related Mozilla "content security policy" work (as well as present W3C work on secure Cross-Origin Resource Sharing) is slated to land.. W3C Web App Security WG charter strawman http://www.w3.org/2010/07/appsecwg-charter.html Content Security Policy http://people.mozilla.com/~bsterne/content-security-policy/ pgut...@cs.auckland.ac.nz also observed: > > Given the million [0] easier attack vectors against > web sites, which typically range from "trivial" all the way up to "relatively > easy" ... > [0] Figure exaggerated slightly for effect. Indeed. WRT to this plethora of web attack vectors, the present patchwork quilt of remedies, and thoughts on how to go about more holistically approaching the issues, please see.. The Need for Coherent Web Security Policy Framework(s) http://w2spconf.com/2010/papers/p11.pdf HTH, =JeffH Internet Standards and Governance Team PayPal Information Risk Management - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
