131–140 of 181 posts
Earlier quoted context omitted.
TLS security is rooted in DNS. It's ACME DNS-01. If your threat model includes nation states, this is a non-solution
Wrong, TLS security is independent from DNS. If my threat model includes nation states I'll trust my own certificates or my very own CA.
Earlier quoted context omitted.
All the CAs are required to log. You don't have to trust any of them. The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.
How can you prove that all CAs log every certificate they produce?
Earlier quoted context omitted.
The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer. Most companies trust their home country as a matter of practicality. Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global ad…
All the CAs are required to log. You don't have to trust any of them. The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.
Earlier quoted context omitted.
How can you prove that all CAs log every certificate they produce?
In addition to what nickf said in the parallel comment, CAs have committed to CT logging as part of being included in browser trust stores. If anyone were to find and report any certificates issued by those CAs via their trusted certificates that were not in CT logs, that would be strong evidence for browsers to remove them from the trust stores, which would essentially destroy their company.
Source: I work in this space
Earlier quoted context omitted.
> you can't fake the SCT entries without having access to the CT private keys. So... Governments like the US and China can fake the entries by using their police forces to seize the private keys? SCT has the same set of problems as TLS - any log will do, not just logs from countries you trust.
This is why multiple SCT entries are required. Could you subvert all of this with enough effort? Yes, and the same is true of dnssec. Any form of cryptographic validation is only as secure as the control of its private keys, but modern TLS is designed to require you to compromise at least 3 independent parties in the TLS ecosystem to provide a plausible fake. And at that point why not just get the browser vendor to p…
To begin with, CAs are allowed to operate logs themselves, so the minimum number of independent parties is 2, not 3.
Second, CT log private keys are not particularly well-protected. They are not stored in HSMs. One log's private key has been presumed compromised since 2020 because the server running the log was pwned via a vulnerability in the Salt configuration management system. SCTs from this log are still accepted by Apple (and by Chrome, until earlier this year) for satisfying the minimum SCT requirement.
Rather, CT provides security by using a Merkle Tree so that SCTs can be audited. In theory, clients can demand proof that an SCT is really included in a log, and gossip tree heads with monitors to ensure that monitors have the same view of the log as them. If an SCT fails auditing, or a log is found to have presented inconsistent views of its Merkle Tree, this can be detected and the log can be distrusted. In practice, this is quite challenging. Apple currently doesn't audit SCTs at all; Chrome probabilistically audits a subset of SCTs.
Earlier quoted context omitted.
Subscribe to CT logs for your domain, and you will know if this ever happens, from LE or from any oher authority. Such attack is a very big deal, if this happens this will only happen once, whichever hole is used will be closed. And if this does not happen, you can be rest assured your TLS is safe. Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even…
> Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even if it was build somehow it will be useless as it has no "teeth" This is a false dichotomy. DNSSEC secures DNS records, it doesn't prevent logging certificate issuance.
That matters because, as the person you were replying to explained, there’s no plausible way to build such a thing. We have CT because the browser developers insisted on it and they control the clients but DNSSEC doesn’t have an equivalent party with that kind of leverage.
Earlier quoted context omitted.
The motivating use case for "cryptographically signing DNS records so they can be validated as being created by the owner of the domain" was the protection of those records in flight, which is something DoH does. A reminder that DNSSEC's "cryptographic security" coalesces to the single AD=true bit in the DNS header by the time DNS responses hit your browser; DNSSEC is a server-to-server protocol. So in almost all cas…
> The motivating use case for "cryptographically signing DNS records so they can be validated as being created by the owner of the domain" was the protection of those records in flight, which is something DoH does. According to the original DNSSEC RFC, RFC2065, the purpose of DNSSEC is to provide data origin integrity and authentication. It also states "In addition, no effort has been made to provide for any confiden…
Earlier quoted context omitted.
That's not how any of this works. Clients don't download the CT logs.
Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding. The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.
So yes, it's true that if an adversary can permanently silo off a client, it can prevent log misbehavior from being detected, either by blocking the reporting of audit failures, or by presenting a completely different view of the log to to the client. However, in many cases it would be impractical for an adversary to keep up such an attack forever, so CT still has value and I'm a huge fan of it. But it's true it can't stop literally all attacks.
Source: I run the CT monitor which has detected misbehavior in multiple CT logs.
Earlier quoted context omitted.
Wrong, TLS security is independent from DNS. If my threat model includes nation states I'll trust my own certificates or my very own CA.
By trusting certificates, you implicitly trust all CAs, not just your own.
In 2020 I scraped fortune top 500 companies for dnssec and found iirc one domain using dnssec. It certainly feels like the wrong way of solving problems (ramming more into the domain registry always seems like a bad option). Is the technology dead or destined to fail? Edit: rationale: dnssec solves domain validity, but https tls solves almost the same problem but has better backing (azure said they don’t support dnss…