If you're thinking about DANE for HTTPS, yes PKIX-EE(1) is reasonably fit for purpose, if/when (some day) the browsers actually implement DANE.
For SMTP, web PKI is not a good fit. See section 1.3 of RFC7672. MTA-STS is a kludge.
WebPKI btw., is just as vulnerable to registrars
Conversation
> For SMTP, web PKI is not a good fit. See section 1.3 of RFC7672. MTA-STS is a kludge.
It works fine. MTA-STS is certainly a kludge since it should just be the only option. People who want to run their own mail server and still receive mail can set up a valid certificate.
1
> WebPKI btw., is just as vulnerable to registrars
CT with enforcement of SCTs at least provides an audit trail to detect a compromise or malicious behavior. There isn't a choice between using Web PKI or DANE since they work fine together. Don't see why someone wouldn't do both.
1
CT works much better in theory than in practice. Only the big players have the resources to audit the logs and determine whether any unauthorised certificates have been issued. It is a pretty high cost to avoid forgery of certificates for Google, and at best works after the fact.
1
It hardly takes a lot of resources, especially for a clean / simple setup. I would expect that the complexity of the setup reflects the resources of the organization and if there's an over-engineered sprawling mess that's a whole separate problem. How are they going to use DANE?
1
If someone can set up DANE, they're in a position to audit CT logs for certificates issued with the wrong key. As I mentioned earlier, I don't see why these things are presented as alternatives when they work fine alongside each other. Doing both is the most practical / secure.
3
DANE is utterly trivial to setup. If anything it's harder for big orgs that have large legacy DNS setups not amenable to DNSSEC (ie Google).
1
I don't disagree with you about DANE being a better approach and easy to setup. I just think that Web PKI has both practical value (dealing with anyone not using DANE) and actual value via CT which can also be considered to place a check on registrars too, not just CAs.
3
I think we've talked about this before and you seem to be misunderstanding my position this time. I don't see a reason not to set up both since it's easy. Can reuse the key when getting a new certificate with LE and now there's actually a verifiable audit trail for certificates.
2
Trusting LE certificates is strictly weaker than DANE. Do you audit the CT logs looking for unexpected certs for your domain? Are you paying someone to do it? How can they tell which certs are legitimate? ... I see lots of smoke and mirrors.
[Yes, it works for Google et. al.]
2
> Trusting LE certificates is strictly weaker than DANE.
It's not and I never said anything about not using DANE.
> Do you audit the CT logs looking for unexpected certs for your domain?
Yes.
> Are you paying someone to do it?
A script is doing it.
Parsing the CT logs has an n^2 cost. Every domain has to read every cert. It only works at scale if the "monitors" are a centralized service you query (and pay). It works now only because almost nobody (tiny fraction) is checking.
1
1
Show replies