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=AFC0FF0DB5C560D3version=liveprid=631314releasejsp=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?)
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?)
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?)
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 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?)
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?)
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 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?)
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?)
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 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
