Re: [cryptography] Is it time for a revolution to replace TLS?
On Fri, 2014-04-25 at 09:28 -0700, Tony Arcieri wrote: There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. It seems we've come to the programming version of the possibilism versus revolution or nothing debate. In politics anyway, the latter attitude leads to nothing rather than revolution. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/14 10:54, Mansour Moufid wrote: On Fri, 2014-04-25 at 09:28 -0700, Tony Arcieri wrote: There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. It seems we've come to the programming version of the possibilism versus revolution or nothing debate. In politics anyway, the latter attitude leads to nothing rather than revolution. I don't think anyone's suggesting that we should rewrite all existing software in Rust (the equivalent of revolution). But it's quite possible to stop writing new software in C. Then we just have to wait 50 or 100 years for most of the existing C code to fall out of use, and we'll have a somewhat improved security landscape. Hooray! I need a drink. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJThblAAAoJEBEET9GfxSfMFzQH/06mPEaJFB+uVftwD4XWHVRy 5pU71JlEJMLIM5d8qF6oczyT4wMOpzankOanDSGGbQnznT+jji/nn5OM4O1Asgbm 7JQovsbNmTENHBXw2Jgk7sxU0+lNaR3ejJH2MyrsLIhrPjayFp8PBXpplWzaHQTL pE2Y1TV5erJwGPL9zHEiH3eF5xB4egW03ZX9t5THCkzOBBoDYYLiYgcTutaV4nNU sQQCPwNOcVhEWDMH65ooVQg1XtsblAySMWy08/kfWerdcf4xQW3rWRKUR1EGHrL/ Qvj1X7GLM6NcIU6xXQ5pEfsaf1itN4yx3IedXupmfx7md3YRzVzgu00kKwgKCOM= =J8dv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Wed, May 28, 2014 at 3:24 AM, Michael Rogers mich...@briarproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/14 10:54, Mansour Moufid wrote: On Fri, 2014-04-25 at 09:28 -0700, Tony Arcieri wrote: There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. It seems we've come to the programming version of the possibilism versus revolution or nothing debate. In politics anyway, the latter attitude leads to nothing rather than revolution. I don't think anyone's suggesting that we should rewrite all existing software in Rust (the equivalent of revolution). But it's quite possible to stop writing new software in C. Then we just have to wait 50 or 100 years for most of the existing C code to fall out of use, and we'll have a somewhat improved security landscape. Hooray! That's already started happening. Microsoft has been pushing .NET in various guises for a while. Most desktop applications don't depend that closely on the underlying C APIs of the operating system. On the server side C seems to be losing ground: not in terms of nginx or Apache, but rather custom servers, where C/C++ is not the only choice anymore. Something like Google's Chromebook is probably exposing much less C to the network then otherwise. Unfortunately there is a catch: Google gets to know what you do with it. One can also do incremental replacement: replace Adobe Reader with something safe, and you close a big attack vector. Why does pine need to be written in C and not Ada or Java? Sincerely, Watson Ladd I need a drink. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJThblAAAoJEBEET9GfxSfMFzQH/06mPEaJFB+uVftwD4XWHVRy 5pU71JlEJMLIM5d8qF6oczyT4wMOpzankOanDSGGbQnznT+jji/nn5OM4O1Asgbm 7JQovsbNmTENHBXw2Jgk7sxU0+lNaR3ejJH2MyrsLIhrPjayFp8PBXpplWzaHQTL pE2Y1TV5erJwGPL9zHEiH3eF5xB4egW03ZX9t5THCkzOBBoDYYLiYgcTutaV4nNU sQQCPwNOcVhEWDMH65ooVQg1XtsblAySMWy08/kfWerdcf4xQW3rWRKUR1EGHrL/ Qvj1X7GLM6NcIU6xXQ5pEfsaf1itN4yx3IedXupmfx7md3YRzVzgu00kKwgKCOM= =J8dv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety. -- Benjamin Franklin ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?
On Tue, May 13, 2014 at 4:23 PM, Phillip Hallam-Baker hal...@gmail.comwrote: In general any proposal of the form 'lets replace X with something 10% 'better'' is a losing proposition. Particularly when we are talking about systems where network effects dominate such as protocols, APIs and keyboard layouts[1]. Does that mean that JSON was more than 10% better than XML, or REST more than 10% better than SOAP? That's not to say that enterprise users don't still make extensive use of the, for lack of a better term, crappier technologies, but for the rest of us, we hopefully don't have those monstrosities in our daily lives anymore. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?
On Thu, May 15, 2014 at 1:26 PM, Phillip Hallam-Baker hal...@gmail.comwrote: JSON is a lot more than 10% better than ASN.1 or XML because both of the latter are bjorked. XML prefixes are insane And TLS isn't? ;) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?
On 15/04/2014 21:07 pm, d...@deadhat.com wrote: http://clearcryptocode.org/tls/ Probably not going to happen, but it's nice to dream... It is one of my long term, implausible goals to replace TLS with a collection of independent app to app function-targeted security protocols that are individually simple enough to understand and implement cleanly. I will certainly fail. It's certainly possible. It's more or less what I do. Adoption and generating the commercial feedback cycle to finance the programmers is the problem, not the technology. E.G. For paying with a credit card.. A secure credit card payment protocol For authenticating a web site and producing keys to bind .. A web page authentication protocol. For remotely logging into a shell producing keys to bind .. A secure shell login protocol. There are many more possibilities. Today, SSL and TLS with all that entails (ASN.1, X.509, PKCS, TCP/IP etc.) is the hammer and any securable thing is the nail. But it's really a client-server session privacy and integrity protocol with issues. It isn't designed to protect my banking transactions, just the traffic over which I communicate my transaction intent. If I had a secure bank transaction protocol independent of TLS, heartbleed wouldn't matter. A classic mismatch between TLS and its primary use securing web traffic is the failure of a virtual server to be able to produce the right cert for the right virtual web site. The cert is really identifying the TLS termination point which may be a web server, rather than a web site, of which the server may be serving many. That's one reason why a web-site security protocol would be more effective than TLS plumbed under HTTP. TLS does need nuking so we can replace it with simpler things. The sentiment isn't wrong, it's just hard to pull off. For amusement, someone pointed me at the tcpcrypt group on the IETF sites. So I spend some days reading and got dragged into conversation. It's weird, I don't think I could design a more flawed process if I tried. But the good thing is that while the IETF working groups are focussed on breaking TCP, others are working to replace it. The question is, how to best replace it? Recent discussions indicate that there are many ways to do this, and the space defies easy cataloging. Which means that the formal, committee, standards, consensus group approaches won't work. How then to replace? And indeed is it a replacement or a bypass, an evolution or a revolution? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Fri, Apr 25, 2014 at 1:42 AM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: As with let's replace C with My Pet Programming Language, you can write crap in any language you want. The problem isn't the language There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. The problem is very much the language. C has too many sharp edges to write crypto code safely. Heartbleed has also done a great job of illustrating that all the band-aids they try to put on these sharp edges are also flawed. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On 04/25/2014 06:28 PM, Tony Arcieri wrote: On Fri, Apr 25, 2014 at 1:42 AM, Peter Gutmann pgut...@cs.auckland.ac.nz mailto:pgut...@cs.auckland.ac.nz wrote: As with let's replace C with My Pet Programming Language, you can write crap in any language you want. The problem isn't the language There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. But that's just cherry-picking, and not a complete argument. Clearly, there are many other important factors to consider (good luck finding a competent rust developer). There are also whole classes of bugs in memory-safe languages that can't occur in C, for example anything related to garbage collection. That's not a complete argument either, but it shows how unconvincing arguments based on individual features must be. The real tragedy is that we still don't know how to develop good software in any scientifically meaningful sense. We have some experimental data, and a lot of folklore, but that's about it. Heartbleed has also done a great job of illustrating that all the band-aids they try to put on these sharp edges are also flawed. Actually, we don't even know what direct damage the vulnerability in heartbleed caused, if any at all. From an economical point of view, heartbleed probably was much less harmful than many other software engineering failures, including those that were done purposefully with good intentions, and/or in safe languages. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Friday, April 25, 2014, Marcus Brinkmann marcus.brinkm...@ruhr-uni-bochum.de wrote: There are also whole classes of bugs in memory-safe languages that can't occur in C, for example anything related to garbage collection. Rust doesn't have a garbage collector. It uses region typing so garbage collection is unnecessary. This is also the main thing that makes Rust an interesting tool for use cases where C/C++ would be the only viable options. Rust is a systems programming language suitable for things like kernel development or RTOS-free bare metal development on microcontrollers. Anyway, I'd suggest reading a bit more about how it works before dismissing it out of hand. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Is it time for a revolution to replace TLS?
http://clearcryptocode.org/tls/ Probably not going to happen, but it's nice to dream... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
