> If the issuer of the DNS challenge flushes its DNS cache and checks with > the authoritative server itself, the propagation delay doesn't seem like > an issue. Are there particular issuers/conditions for which you believe > the issuer would have to rely on caching resolvers?
This works, but there exist DNS providers where updates to even their own nameservers take tens of minutes or more, or at least are not guaranteed to take less than that. These might be quite crummy DNS providers, but they don't appear to be rare. Keep in mind that if a challenge fails, the entire authorization is deemed invalid and must be restarted. So it's very easy to fail an authorization and have to start over again. I think this property, combined with the non-determinism of DNS challenges, makes the dns challenge type impractical as it currently stands. Moreover, with a deterministic challenge you can renew the authorization trivially, enabling automatic certificate renewal in the case where automated connection of /.well-known/acme-challenge or TLS-SNI is infeasible or more complex. While these cases will hopefully not be common, endorsing an account key in DNS seems like a simple and low-maintenance solution. > Can you provide text for what you propose? I'm having a bit of trouble > parsing your intent. Let's say that the DNS challenge was changed so that the following format is used: _acme-challenge IN TXT "a=<base64 SHA-256 hash of account JWK in canonical form>" This provides essentially equivalent security to trusting unsigned A/AAAA records. Arguably, the security is marginally higher, since an entity which can't forge DNS but can MitM all validation queries going to a server can't get a certificate unless it gets the account key. (One alternative might be to use CAA records, but that would have the potentially undesired side effect of preventing the use of other CAAs, and while the CAA specification envisions the use of account identifiers, the purpose of that is to restrict, not to authorize.) _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
