Why not hard-fail by default and give the user the option to ignore/override it? Similar to the way other certificate warnings are shown to the end-user.
No, don't enable revocation checking
21–30 of 157 posts
Re: No, don't enable revocation checking
#22For those, like me, wondering who the author might be, it appears to be this guy: "Adam Langley works on both Google’s HTTPS serving infrastructure and Google Chrome’s network stack. From the point of view of a browser, Langley has seen many HTTPS sites getting it dreadfully wrong and, from the point of view of a server, he’s part of what is probably the largest HTTPS serving system in the world - See more at: http:/…
He was also one of the two people who prepared the fix for Heartbleed in OpenSSL[0].
[0]: https://github.com/openssl/openssl/commit/731f431497f463f3a2...
Re: No, don't enable revocation checking
#23Could we use bloom filters on the CRLs, before checking with OCSP? Maybe I should go crunch the numbers on the viability of that.
Re: No, don't enable revocation checking
#24Earlier quoted context omitted.
Want to help us work on this problem at http://telehash.org ?
I remember reading something about that before. I just had a quick look around and, while I don't believe I have fully groked the concept it would seem to me that Telehash is solving a different, but related problem. The web, as a technology is probably not going anywhere for a few more decades at least - people have gotten very used to opening up a web browser - very few actually understand the technology beneath. T…
Just to be clear, Telehash is a protocol, not an application. The bulk of the documentation is on Github, and so far it's mostly for people implementing the protocol in different languages.
There's no blockchain involved in Telehash. It accomodates various cipher sets, including one suitable for ultra low power devices (there's a partially working implementation for Arduino). And you're correct, it isn't really aimed at enabling anything like trusting a URL from a television commercial.
Telehash is conservative in the sense that it solves useful problems, even within the current DNS infrastructure. No one's currently doing this, but you could easily map a DNS name to a Telehash address. But it also offers global resilience to partitioning, because the logical mesh can operate on any lower level network transport.
I like the multiple notary model of Convergence, but I think any of these trust models still need to separate the "human memorable names" component.
Re: No, don't enable revocation checking
#25Why not hard-fail by default and give the user the option to ignore/override it? Similar to the way other certificate warnings are shown to the end-user.
answered in adam's blog; see the paragraph beginning with
Everyone does soft-failRe: No, don't enable revocation checking
#26I would feel better if the author actually knew the name of the bug he was talking about...
Re: No, don't enable revocation checking
#27Earlier quoted context omitted.
Why have a single entity at all? Moxie Marlinspike proposed Convergence ( https://www.youtube.com/watch?v=Z7Wl2FW2TcA ) as a solution - I think that something like that has far more potential wheels to travel than a Namecoin based system. I should be able to choose who I trust, a notary system would allow me to do just that. No central CA systems. The biggest concern I can see is Identity management, but, as mentione…
> Why have a single entity at all? How do you figure that Namecoin is a "single entity"?
There is one blockchain. The security of the blockchain requires everyone working very hard to maintain it - while it is made out of many parts it is 1 entity (like an ant colony).
Contrast with something like Convergence, where, while they share a common protocol (maybe...not necessarily) each part is responsible for itself, and not tied to any particular larger whole.
Re: No, don't enable revocation checking
#28Earlier quoted context omitted.
I remember reading something about that before. I just had a quick look around and, while I don't believe I have fully groked the concept it would seem to me that Telehash is solving a different, but related problem. The web, as a technology is probably not going anywhere for a few more decades at least - people have gotten very used to opening up a web browser - very few actually understand the technology beneath. T…
Just to be clear, Telehash is a protocol, not an application. The bulk of the documentation is on Github, and so far it's mostly for people implementing the protocol in different languages. There's no blockchain involved in Telehash. It accomodates various cipher sets, including one suitable for ultra low power devices (there's a partially working implementation for Arduino). And you're correct, it isn't really aimed…
I was mixing a number of different criticisms of various technologies in my post...I never meant to confer that Telehash has a blockchain.
I guess, I still don't understand the point of Telehash. Even having read through the documentation. "Establishing private communication channels" is definitely a big problem, one with a huge threat model, and the solution is probably multi-faceted - I don't see where a system like Telehash fits in v.s. something like tor or i2p for example - does anonymity fit into the threat model?
Before dragging this thread off the page I will follow up with an email. :)
Re: No, don't enable revocation checking
#29It seems the only problem with hard-fail is the risk of DoS attacks by targeting OCSP servers. However, if you include OCSP stapling you won't be affected. So a solution may be to encourage all users to enable revocation checking with hard-fail, and all servers to support OCSP stapling.
Re: No, don't enable revocation checking
#30It sounds like the internet is broken Without CRL/OSCP we cannot truly trust that we are securely communicating.
Something has to give. We need to abolish SSL/TLS and migrate to something that isn't broken by design