Subject: [Acme] Stale DNS and high-risk issuance

From: Kevin Borgolte <[email-masked]>
Date: Fri, 29 Dec 2017 22:43:43 +0100

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?

If you are interested in reading the paper, please reach out. While we
have not made the paper public yet, we are happy to share it privately
here.

Best,
Kevin

P.S. We plan to release the paper publicly early January.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 30 Dec 2017 13:05:27 +0200

> for the proposed ACME challenge, or would you want to incorporate it

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