41–50 of 81 posts
Do you rely almost exclusively on the first connection to a server being correct? Apparently. Does SSH? No.
Earlier quoted context omitted.
Good, come back when it's standardized. Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto
I thought part of successfully killing off '90s crypto was deploying useful, obviously-correct systems without waiting for standards committees to bikeshed them to death (cf. CFRG).
So as I read #1, I'm trying to figure out what angle they're trying to argue here. The fact that the current TLD and CA systems are baked around the concepts of central authorities who are controlled either directly or indirectly by governments is known, and it's not a valid justification for DNSSEC also having that same pitfall. We're already well aware of the threats to security that come from centralized control l…
The argument is that if you choose a traditional TLD your eggs are in the centralized basket. All of the mitigation techniques proposed by Marlinspike for HTTP can be applied at the DNS level as well. And even if you choose a decentralized DNS solution, you still need DNSSEC. The point is that DNSSEC has little to do with the centralization issue and that it can do a lot to improve the security and privacy of the Int…
But that's not true. DNSCurve does provide a decentralized trust mechanism. If you are willing to embrace the pitfalls and advantages of such an approach, you don't need DNSSEC.
Earlier quoted context omitted.
Have any CAs publically committed to submit all their generated certs to that? Does https://pki.google.com/ do that?
Chrome currently requires that all extended-validation certs with an issuance date of 1/1/2015 or later be submitted to the CT logs. (Otherwise it will not show up in the UI as an EV cert.) As with all browsers, only a subset of CAs are trusted to provide EV certs in the first place, regardless of whether they include the EV bits in the certificate. And this policy only applies to EV certs, not to all certs by an EV-…
Oddly enough I noticed the other day that certificate-transparency.org isn't even accessible over https.
Earlier quoted context omitted.
Chrome currently requires that all extended-validation certs with an issuance date of 1/1/2015 or later be submitted to the CT logs. (Otherwise it will not show up in the UI as an EV cert.) As with all browsers, only a subset of CAs are trusted to provide EV certs in the first place, regardless of whether they include the EV bits in the certificate. And this policy only applies to EV certs, not to all certs by an EV-…
With some exceptions, at least. For example, twitter.com shows up as an EV green bar while my browser tells me there's no CT information available. The CT website mentions a list of exceptions would be generated but I haven't been able to find any public list, and there's been no update to their rollout plans in over 7 months[1]. Oddly enough I noticed the other day that certificate-transparency.org isn't even access…
(Eventually this should go away because a compromised CA key can obviously just lie about the time, but this is just a migration step.)
Earlier quoted context omitted.
Can you provide an NSEC white-lie response to an arbitrary query without an online key? (I'm not sure if this is what was being asked, but I'm curious about the answer to that, either way.)
Don't think so.
(Phreebird is an online signer, but I don't see why an offline signer couldn't generate these proofs.)
Earlier quoted context omitted.
With some exceptions, at least. For example, twitter.com shows up as an EV green bar while my browser tells me there's no CT information available. The CT website mentions a list of exceptions would be generated but I haven't been able to find any public list, and there's been no update to their rollout plans in over 7 months[1]. Oddly enough I noticed the other day that certificate-transparency.org isn't even access…
The twitter.com cert I see in my browser was issued on 9 September 2014, which is before the 1 January 2015 threshold. (Eventually this should go away because a compromised CA key can obviously just lie about the time, but this is just a migration step.)
Earlier quoted context omitted.
Ah, I think the delegation problem with the X.509 / HTTPS PKI is a (fairly massive) implementation facepalm, not anything inherent to a PKI itself. So I think that's why people were confused by your statement "DNSSEC got PKI wrong" -- that doesn't seem wrong , it seems like a good thing for a PKI to support this. Do you think that a DNSSEC replacement should match the X.509 PKI in this regard?
Ah, that makes sense. Sorry for the confusion I created. I meant that DNSSEC PKI is wrong in the sense that it is hierarchical, and the root keys are centrally controlled by a biased party. A better PKI would probably look like Convergence [1], where trust is derived from a hybrid CA/"web of trust" system formed by a network of notaries. The delegation implemented in DNSSEC is a good thing. I didn't think about how t…
As covered in the article, Convergence-style triangulation of cryptographic information is application/protocol neutral. Indeed, a DNS-level implementation would be much more powerful than what can be accomplished with HTTPS.
Earlier quoted context omitted.
> "There are methods to prevent leaking" isn't the same as "leaking is prevented by default." This is from the zone enumeration section and plain DNS doesn't do anything to prevent zone enumeration by default either. > EdDSA We are working on standardizing EdDSA, but it takes a long time to get to deployment.
Good, come back when it's standardized. Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto
If you read TFA you would see that we are transitioning to P-256. FWIW, ECC crypto is really slow and we will need to transition to post-quantum crypto in another 10 or 15 years.
Earlier quoted context omitted.
The argument is that if you choose a traditional TLD your eggs are in the centralized basket. All of the mitigation techniques proposed by Marlinspike for HTTP can be applied at the DNS level as well. And even if you choose a decentralized DNS solution, you still need DNSSEC. The point is that DNSSEC has little to do with the centralization issue and that it can do a lot to improve the security and privacy of the Int…
> And even if you choose a decentralized DNS solution, you still need DNSSEC. But that's not true. DNSCurve does provide a decentralized trust mechanism. If you are willing to embrace the pitfalls and advantages of such an approach, you don't need DNSSEC.
Dan Kaminsky did a good job taking DNSCurve apart back in 2011: http://dankaminsky.com/2011/01/05/djb-ccc/
"I observe this is essentially a walk of Zooko’s Triangle, and does not represent an effective or credible solution to what we’ve learned is the hardest problem at the intersection of security and cryptography: Key Management. I conclude by pointing out that DNSSEC does indeed contain a coherent, viable approach to key management across organizational boundaries, while this talk — alas — does not."