The Hacker‘s ChoiceDRAFT Release: Don't share outside mastodon yet. Please comment and review :>
joernchen 
@thc I mean the ACME RFC states it already
An active attacker on the validation channel can subvert the ACME
process, by performing normal ACME transactions and providing a
validation response for his own account key.
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-10#section-10
Automatic Certificate Management Environment (ACME)
Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org).
Frederik Braun �@joern @thc Regarding the proposed changes:
1. CT already has a bandwidth/storage/scalle issue. Convincing someone to include more data is unlikely to succeed.
2. CAA checking in the browser would be an interesting experiment. Many already query DNS HTTPS resource records. But as you say, CAA adoption is very low.
3. Could we make ACME renewal behind HTTPS such that only the first certificate is unencrypted?
1. CT already has a bandwidth/storage/scalle issue. Convincing someone to include more data is unlikely to succeed.
2. CAA checking in the browser would be an interesting experiment. Many already query DNS HTTPS resource records. But as you say, CAA adoption is very low.
3. Could we make ACME renewal behind HTTPS such that only the first certificate is unencrypted?
@joern @thc Wait, I am slowly waking up 🥴.. How does CAA actually help though? It's a record to tell the world which certificate authority is allowed to create certs for a domain. But if you already use ACME with a specific CA, then the attack would just be confined to that very same specific CA. That doesn't really limit the attacker in any kind of way, does it?
Antonis CharitonCAs have to perform one of the methods described in the CA/B Forum Server WG Baseline Requirements under 3.2.2.4. Perhaps with the acceptance of enough CAs and Browsers we can introduce a new method but requiring the previous certificate to get a new one has been a challenge for other protocols based on it like SCEP.
So far we focused on making verification better (you need to compromise all traffic) and results visible (CT). I think ACME challenges are the most (1/2)
@antonis @freddy @joern I can see the challenge with “new very only if you know old cert/key” but also feel it’s the obvious and easiest next move as a defender: enforce this only if mode=strict is set in the CAA record. If it fails then owner shall only be allowed to download new cert via web-login + 2FA or owner must temporarily remove mode=strict.
Still doesn’t solve the problem that almost nobody uses CAA. It’s a niche for nerds. The CA and (later) the browser manufacture could make “no CAA” far less appetising than CAA…..
Still doesn’t solve the problem that almost nobody uses CAA. It’s a niche for nerds. The CA and (later) the browser manufacture could make “no CAA” far less appetising than CAA…..
Correct, there are 3 things here to note:
1) Downgrade attacks. I don't *have* to use the new super-secure challenge, I can always use HTTP-01 if I am an attacker with MITM access.
2) The CAA record is still required for protection as today all CAs are trusted equally. Without it, any CA with broken processes can fall back to phone / fax / mail / e-mail / ... and since there's a very long tail of quality, it'll work.
3) Most domains by count have DNS + WWW on the same IP
Exactly, and that's the spirit. Try to protect as many properties or users as you can, by default, without necessarily involving operators that may not know about the existence of all these things or have the time to configure them.
This is why I think all these plaintext challenges have been successful. They were not nihilistic and 100%-secure-or-nothing, but worked good enough in reality and beat the alternative.
That's why MPDV reduces risk by moving work to the CA too