On Sun, Oct 21, 2018 at 09:37:18AM +0000, Tobias Fiebig wrote:
> Dear all,
> At the IETF in Montreal, I presented findings on security issues with
> domain validation in ACME, and were encouraged to write a short draft
> outlining attacks and possible defenses. We now created a first
> draft, which outlines the general structure and contents we are
> aiming for, see https://datatracker.ietf.org/doc/draft-fiebig-acme-esecacme.
> We are looking forward to your input on our plans.
Some quick comments / questions.
- With IP/Resource-use-after-free, how often are all the resources
abandoned (making the site completely non-operative) versus only some
resources abandoned (so it at least intermittently works)?
It seems that if it is only some resources have been abandoned, one
could try multiple validations with random target addresses, which is
highly likely to discover inconsistent address record sets.
- If DNSSEC fails ("bogus"), the CA should not issue at all.
- Private keys get lost all the time. Any sort of manual effort from
the part of CA to recover is not acceptable for any sort of CA with
large volume-to-size ratio.
Additionally, one has to be careful that the PoP mechanism is
cryptographically kosher. For example, using TLS key for JWS is not
kosher. Most of these mechanisms would require ACME extensions
anyway. With exception of taking the public key from CSR, but that
appears only after all validations have completed.
Then there are those that think rotating signature keys is somehow
"essential" to security.
- EV is probably excessive bar for additional validation. For example,
AFAIK, natural persons can not get EV certificates, only legal
persons can.
- Preceptions of GDPR are creating problems linking DNS names to real
world identities. CA/Browser forum is discussing additional
validation methods to essentially put data once found from WHOIS to
DNS because GDPR drove multiple provoders to censor the WHOIS data.
- There is no E-Mail verification for ACME.
- Deploying DNSSEC can be pretty high bar (unfortunately).
- Deploying TLSA is even higher bar, due to requirement to hold down
keys on change. This is not supported by most ACME clients. It
would also impact container setups.
- If site truly changes ownership, it should be treated as new
site for validation. Because it is a new site, despite having
the same name as site that once existed.
- Some additional hardening options for CAA could actually be useful.
Unfortunately, most deployment here is blocked due to bugs in
RFC6844.
E.g., public key pinning on issuance via CAA (I had that idea
a while back, in order to limit the damage compromised
certificate automation could cause). Or expanding TLSA records
to such sets.
-Ilari
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
