On Fri, Dec 29, 2017 at 10:43:43PM +0100, Kevin Borgolte wrote: > Hi all, > > we have reached out a while ago about IP address staleness and domain > takeover attacks, and a way to prevent certificate issuance in these > cases (July 2017). > > Since then, we have conducted some measurements on the practicality of > the attacks. Furthermore, we wrote down our defense in a structured > manner. The results of this will appear as a paper at the Network and > Distributed Systems Symposium (NDSS) in February 2018. > > As you suggested when we approached the list earlier, we would love to > contribute a RFC on it. However, based on that initial feedback, we > were wondering how to move forward? Would you prefer an additional RFC > for the proposed ACME challenge, or would you want to incorporate it > into an existing RFC?
I think it is bit too late for the existing RFC. So it would have to be new RFC. Which means you would need to post draft for it. I think there would be much to discuss about ecosystem impact on the proposed countermeasures[1], and also cryptographic cleaniness (e.g., it is not cryptographically kosher to use TLS private key for JWS[2]). [1] Just as example, the following kinds of stuff are (legimately) seen fairly often or more: - Rolling over the account key for each renewal (this is usually caused by containers forgetting things). - Rolling over the TLS key for each renewal (some actually recommend this, I do not). Sometimes with very frequent renewals. - Getting multiple certificates with different keys for multiple servers with the same name. - Handling validation on separate system and pushing the certificates (and likely the TLS keys too, probably not in safe manner!) to server systems. These systems might utilize HTTP redirects (which HTTP-01 does follow) or DNS CNAMEs (which DNS-01 does follow). - Users wiping out the TLS keys and account keys (without backup!) to "reset" something (admin mistake). - Transferring site between servers and losing the keys (account and TLS) in the process. - Users using all sorts of whacky ACME clients that just do not implement anything more than bare minimum for the common case. - Users using HTTPS on servers they don't have proper control of DNS for (can't edit records, or can only use very few record types, at worst only A/AAAA, or worse yet, A only). Thinking about recovery is rather important. One of the major reasons HPKP is so hated is lack of pretty much any kind of recovery. [2] This was actually one of the major reasons why the PoP challenge was removed. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
