Great news! Hopefully between LibreSSL and BoringSSL, OpenSSL will go away and never return. I think AGL and the LibreSSL team will be able to do some fantastic informal collaboration. I'm looking forward to a healthy TLS ecosystem.
That's pretty brutal. One reason why Heartbleed was such a potential problem was the monoculture that tends to come when FOSS software becomes reliable and popular. Having more options out there is good, but I don't see why OpenSSL needs to go away. It had one major zero-day, then when people started paying attention to it, it got 1. a lot of attention to its security and 2. a not insignificant increase in much-needed financial support. Hopefully, we'll see more stable and well-tested TLS libraries out there, and the fact that there are now a few forks of OpenSSL is a good start.
Not that I necessarily disagree with you, but I do want to add two points for consideration:
1. a lot of attention to its security
That doesn't help if bug reports rot in the tracker for years. The developers' attitude might have changed under the current media attention, but for how long will that last? I have yet to read a public statement by the OpenSSL team on how they plan to improve code quality and processes in the long run.
2. a not insignificant increase in much-needed financial support
Actually, if anything, the story is proof that the routers are not backdoored from the start
Let me preface my response by saying I think there are probably more non-malicious (accidental) vulnerabilities than intentional backdoors.
Schneier has seen many of the original documents, and his constant refrain is that NSA programs are robust -- that they have multiple totally unrelated ways to accomplish any one goal. Quoting one of his articles:
"First and foremost, the surveillance state is robust. It is robust politically, legally, and technically. I can name three different NSA programs to collect Gmail user data. These programs are based on three different technical eavesdropping capabilities. They rely on three different legal authorities. They involve collaborations with three different companies. And this is just Gmail. The same is true for cell phone call records, Internet chats, cell-phone location data."
The data in root "." is controlled by ICANN, a US corporation. The data in the most important gTLD, .com, is run by Verisign on contract with the US Chamber of Commerce. The ccTLDs (.fr, .tw, etc.) are controlled by world governments.
Sure, the root and major TLDs are anycasted across the globe, but the "wide range" of organizations are just mirroring content that is in one way or another controlled by world governments, and given (for example) ICE domain seizures, it would be prudent not to over-rely on DNS. Personally I support DNSCurve as a means to secure DNS, not to replace security we already have elsewhere.
I guess we'll have to agree to disagree. I've worked with the ICANN DNS people enough and am aware of their practices enough (ex. https://www.iana.org/dnssec/icann-dps.txt ) that I don't see how the root zone could be compromised without people knowing.
OpenBSD did not upgrade to 2.X. You're talking about ports, which are separate from the base operating system. For accurate information about OpenBSD, right now, check:
Regarding ports, they're basically a compilation build system that complements binary packages (which OpenBSD also has) for 3rd party software not installed with the base system . See:
This is OpenBSD's fork of Apache 1.3. It runs chroot and privsep'd by default, and of course is patched for security issues where necessary. (OpenBSD recently dropped Apache from the base build and is now fully committed to nginx, moving forward.)
You're missing the major point: MinimaLT will initially use X.509 (since it's already deployed). A future protocol upgrade will support, if I'm not mistaken, sayI.
DNS Security (e.g. DNSCurve, DNSCrypt, or even DNSSEC) adds a second layer of security: keys are transmitted in DNS records, and server auth is done via X.509.
This means an attacker would have to break both X.509 _and_ DNS.
I'm not sure if this is more secure; in fact, I think it's less secure than SSL
I believe the above point addresses your concern. In addition, MinimaLT's Curve25519 + Salsa20-Poly1305 is superior to any ciphersuite found in TLS.
With serious protocol designers now largely side-stepping the IETF due to BULLRUN infiltration, BLAKE2 and other non-standard primitives have a better shot than before of seeing mass adoption. I hope to see BLAKE2 widely used in the future.
I also hope to see more non-standard crypto and protocols, where "the market" leads the way, and standards groups try to keep up in order to appear legitimate.
> I also hope to see more non-standard crypto and protocols, where "the market" leads the way
This is super-dangerous, unless the amorphous "market" is also paying for cryptanalysts to bang on the crypto primitives as a public service to all competitors in the market.
After all, RSA adopting Dual EC DRBG was a business decision, and one which the market didn't reverse despite Dual EC DRBG being publically known to have a probable backdoor since 2007.
Maybe we're using different definitions of standardization.
The IETF writes RFCs which developers are expected to follow, and (mostly) do. This is a standardization of sorts, but it's beside the point I was making.
I'm not talking about Joan Daemen wrt BULLRUN. I'm referring to secure protocols that offer RC4 but not Salsa20, TLS without a single constant time cipher, 112-bit security, secure protocols that aren't even encrypted, null ciphers, Dragonfly, cipher suites so complex that they're expected to be implemented wrongly, secure protocols made so complex they won't be used at all, crypto advisory groups run by NSA employees, etc.
TLS offers RC4 and not Salsa20 because RC4 existed when SSL was first defined by Netscape, and Salsa20 didn't, and wouldn't for over a decade.
It's worth mentioning here that the "encrypted by default" Internet that was the dream of the 1990s was a government project, and TLS more or less thwarted it.
Different ciphers can be more or less straightforward to implement without timing leaks, but "constant time" is a property of an implementation, not of a cipher.
Dragonfly is exceedingly lame, but it's also completely inside-baseball. Even if Dragonfly had been "standardized" by the TLS WG, nobody ever would have used it, because nobody ever used SRP either, and SRP was better.
The ciphersuites in TLS aren't complicated. They're very simple. The problem with TLS ciphersuites isn't that they're complicated but that they're wrong. Which is unsurprising, because they were designed before anything like Bellare and Namprempre; in fact, they were designed in an era where many practitioners believed that message authentication was unnecessary for cryptosystems at all.
I'm not sure which complex secure protocols you're referring to. TLS and SSH are so widely used it seems fair to call them universal.
As for the CFRG chair, well, I won't repeat myself:
In the end, though, the real issue I have with your comment is that the IETF has nothing at all to do with BLAKE2's standards- friendliness. The IETF will soon standardize ChaCha20-Poly1305 for TLS, for instance, despite the fact that no NIST standard will ever do the same.
You don't need to run OpenSMTPD in order to get Xorg to work, of course. Also, OpenBSD is just the operating system. You can run whatever MTA you want.
Just a reminder, this thread is about Xorg running without privileges on OpenBSD -- an amazing feat!
When your tools are secure, they work for you and not the other way around.