[colmmacc]

That seems exactly backwards.

With DNSSEC zones are controlled and signed by a single authority, and for CCTLDs that authority is controlled by ... the government. If they wanted to produce a malicious signature and serve it narrowly to a targeted victim ... that's quite doable with little in the DNSSEC system to prevent it.

While it's true that there many TLS root cert operators and some probably could be compromised by a government (though I wouldn't say "trivially"), there is also a gigantic mutual destruction pact in the form of certificate transparency that means all certs issued are visible in transparency logs and there are quite sophisticated technical and social controls in place to detect malicious certs. The cert operator would be imperiling their business and future trust in a way that isn't as true for DNSSEC.

[matthew9219]

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 adversary just compromises the channels used to obtain the transparency logs and to report violations. It seems to work for mobile consumer devices like cel phones, because these devices naturally connect to many different networks, of which only some are compromised.

[tptacek]

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.

[matthew9219]

Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome.

For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long might such a compromise go undetected? Is there any reason to think it'd ever be detected?

CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. For homogenous configurations (like the implementations of AWS, Azure, or GCM, or the deployment of routers, IOT devices, or gaming systems), it seems like a competent global adversary would simply figure out how to go unreported for that configuration, and nobody would particularly check.

[woodruffw]

> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients.

Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties.

In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).

[matthew9219]

The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates.

Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.

[tptacek]

That's not how any of this works. Clients don't download the CT logs.

[akerl_]

I'm not sure why you're so fixated on this idea of client systems monitoring CT logs.

Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.

[matthew9219]

In the attack DNSSec prevents, a client is compromised by a cert that doesn't appear in the CT logs, so infrastructure monitoring is irrelevant.

[mjg59]

Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.

[tzs]

I don't think firmware updates for routers is a good example. That seems more like the kind of situation where you should actually be using your own PKI.

[teddyh]

Even if you trust the current CAs (all of them) to not intentionally issue bad certificates, you must also trust all of them not to have their systems broken into. If even one CA gets compromised, the hackers can issue certificates for any name.

[AndyMcConachie]

How can you prove that all CAs log every certificate they produce?

[nickf]

You can't, but a certificate that isn't logged won't work for the overwhelming majority of practical use-cases (ie any Google or Apple owned product). If you need a certificate that doesn't care about those, you perhaps don't need a publicly-trusted certificate in the first place.

[akerl_]

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.

[agwa]

That is not true. CAs are not required to log their certificates. Instead, Chrome and Safari by default do not accept certificates unless they are accompanied by a signed receipt from a recognized log. If you don't need your certificate to work in a default-configured Chrome or Safari there is no need for your certificate to be logged.

Source: I work in this space

[tptacek]

Here what you really mean is "if your certificates will never touch Chrome", because it's not just that Chrome won't accept them, but that Chrome's SCT auditing is part of a surveillance system for certificate misissuance.