Subject: [Acme] ACME DV Security Considerations Draft

From: Tobias Fiebig <[email-masked]>
Date: Sun, 21 Oct 2018 09:37:18 +0000

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. 

Met vriendelijke groet,
 
Dr.-Ing. Tobias Fiebig,
Assistant Professor / Universitair Docent
Department Engineering Systems and Services

Informatie- en Communicatie Technologie (ICT)
 
TU Delft / Dept. ESS
Faculty of Technology, Policy and Management (TBM)
Building 31
Jaffalaan 5 - room B3.170
2628 BX  Delft
P.O.Box 5015
2600 GA Delft, The Netherlands
T +31 (0)15 27 85700
E  [email-masked]

Present: Monday t/m Friday

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 21 Oct 2018 20:31:16 +0800

Thanks for posting this.

It does not seem to be related to ACME - that is, what you’re describing is
more broadly a set of concerns with the methods that may be used to
validate a domain. For example, ACME is a strict, well-defined subset of
that which permitted by the CA/Browser Forum’s Baseline Requirements. By
focusing only on ACME, it seems like it leaves significantly greater risk
that other CAs will fail to adopt mitigation’s.

That said, I do have to disagree with the very premise of High Risk
Domains. That’s a sort of discussion without data, especially since EV does
not meaningfully provide any security benefit to domain validation. As that
seems to mix personal opinions with otherwise well founded recommendations,
could you speak to why you believe there’s any value in those approaches?

On Sun, Oct 21, 2018 at 6:38 PM Tobias Fiebig <[email-masked]> 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.
>
> Met vriendelijke groet,
>
> Dr.-Ing. Tobias Fiebig,
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 21 Oct 2018 19:44:23 +0300

On Sun, Oct 21, 2018 at 09:37:18AM +0000, Tobias Fiebig wrote:
> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 21 Oct 2018 17:25:40 +0000

*   It does not seem to be related to ACME - that is, what you’re describing is more broadly a set of concerns with the methods that may be used to validate a domain.

Perhaps ACME isn’t the right place for this, perhaps it should be reviewed by SecDispatch, or whatever the DNS equivalent is, or coordinated between the two area AD’s.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Oct 2018 17:48:04 -0500

> Perhaps ACME isn’t the right place for this, perhaps it should be reviewed by SecDispatch, or whatever the DNS equivalent is, or coordinated between the two area AD’s.

Since there are proposed solutions in here, secdispatch would seem like a
fine place (and the latest agenda I saw for them had some slots free,
still).  There might also be a place for a more open-ended discussion of
problems with DV in SAAG, if someone were to volunteer to prepare some
slides and structure the discussion.

-Ben

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 21 Oct 2018 21:01:35 -0400

On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk <[email-masked]> wrote:

> >   *   It does not seem to be related to ACME - that is, what you’re
> describing is more broadly a set of concerns with the methods that may be
> used to validate a domain.
> >
> > Perhaps ACME isn’t the right place for this, perhaps it should be
> reviewed by SecDispatch, or whatever the DNS equivalent is, or coordinated
> between the two area AD’s.
>

Thanks. I agree secdispatch is probably a better place for this. The
CA/Browser Forum's Validation WG attempted to perform a similar analysis
during it's F2F in Herdon, VA, as captured ever so briefly in
https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/
. This was the first (and only) meeting in which the Forum Chair extended
blanket invitations for experts to participate, and while well-attended, is
nowhere near the open participation model that the IETF represents. Work on
attempting to resolve some of the security concerns is captured in
http://cabforum.org/pipermail/validation , although the limited
participation (largely of CAs) prevents a lot of the thorough analysis this
work represents, and having a broader participation such as through
secdispatch is better for the ecosystem as a whole.

One minor pedantic quibble, however, is that I think the discussion would
be better served by not speaking of it as ACME or DV. The notion of
"DV/OV/EV" is an arbitrary marketing distinction with no security value -
all certificate types rely on the same procedures for validating an
assertion of control (organizational or operational) over a domain name.
Indeed, in many cases, forms of certificates such as OV/EV have been
demonstrated to be significantly weaker in practice - for example, that the
organization name in WHOIS (i.e. "Google, Inc") matches an incorporated
institution somewhere named the same - without any further validation about
which "Google, Inc" is being referred to, soft-matches such as "Google,
LLC", or even relationships such as "There's a Google LLC as a subsidiary
of Alphabet, and this company's name is Alphabets, so that's probably OK".

By speaking more generally of the challenges of validating a domain, we
allow speaking with precision without the distinction of marketing or
branding, and addressing the underlying security issues more directly.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Oct 2018 18:42:55 +0000

Following Ben’s suggestion, this draft is being moved to SECDISPATCH for discussion.

Thanks!

From: Ryan Sleevi <[email-masked]>
Date: Sunday, October 21, 2018 at 9:01 PM
To: Benjamin Kaduk <[email-masked]>
Cc: Rich Salz <[email-masked]>, Ryan Sleevi <[email-masked]>, Tobias Fiebig <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Acme] ACME DV Security Considerations Draft

On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

Thanks. I agree secdispatch is probably a better place for this. The CA/Browser Forum's Validation WG attempted to perform a similar analysis during it's F2F in Herdon, VA, as captured ever so briefly in https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/<https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_2018_03_08_final-2Dminutes-2Dfor-2Dca-2Dbrowser-2Dforum-2Df2f-2Dmeeting-2Dherndon-2Dva-2D7-2D8-2Dmarch-2D2018_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=lSV2-wQf6qsDc7B3upJkBp4mBQIkoHvnsHwGEzVXzhI&s=QOfpyh2h4uto88ihDjPZuQj7aGQLe9zqEVXUjSkYlTk&e=> . This was the first (and only) meeting in which the Forum Chair extended blanket invitations for experts to participate, and while well-attended, is nowhere near the open participation model that the IETF represents. Work on attempting to resolve some of the security concerns is captured in http://cabforum.org/pipermail/validation<https://urldefense.proofpoint.com/v2/url?u=http-3A__cabforum.org_pipermail_validation&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=lSV2-wQf6qsDc7B3upJkBp4mBQIkoHvnsHwGEzVXzhI&s=UEjruCF6pq9gzj5WFV0vgCmoXHnK6tkQIiw_Y3HDU3Q&e=> , although the limited participation (largely of CAs) prevents a lot of the thorough analysis this work represents, and having a broader participation such as through secdispatch is better for the ecosystem as a whole.

One minor pedantic quibble, however, is that I think the discussion would be better served by not speaking of it as ACME or DV. The notion of "DV/OV/EV" is an arbitrary marketing distinction with no security value - all certificate types rely on the same procedures for validating an assertion of control (organizational or operational) over a domain name. Indeed, in many cases, forms of certificates such as OV/EV have been demonstrated to be significantly weaker in practice - for example, that the organization name in WHOIS (i.e. "Google, Inc") matches an incorporated institution somewhere named the same - without any further validation about which "Google, Inc" is being referred to, soft-matches such as "Google, LLC", or even relationships such as "There's a Google LLC as a subsidiary of Alphabet, and this company's name is Alphabets, so that's probably OK".

By speaking more generally of the challenges of validating a domain, we allow speaking with precision without the distinction of marketing or branding, and addressing the underlying security issues more directly.

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 24 Oct 2018 16:06:44 +0000

It is worth noting that the need for an invitation only apples to Face to Face meetings.  There is no restriction on who can be an Interested Party and participate in working groups and subcommittees, as long as you are able to sign the Intellectual Property Rights agreement.  I’d encourage anyone interested in discussing this issue there to do so.

-Tim

From: Acme <[email-masked]> On Behalf Of Ryan Sleevi
Sent: Sunday, October 21, 2018 9:02 PM
To: Ben Kaduk <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Salz, Rich <[email-masked]>; [email-masked]; IETF ACME <[email-masked]>; Tobias Fiebig <[email-masked]>
Subject: Re: [Acme] ACME DV Security Considerations Draft

On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]> > wrote:

Thanks. I agree secdispatch is probably a better place for this. The CA/Browser Forum's Validation WG attempted to perform a similar analysis during it's F2F in Herdon, VA, as captured ever so briefly in https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/ . This was the first (and only) meeting in which the Forum Chair extended blanket invitations for experts to participate, and while well-attended, is nowhere near the open participation model that the IETF represents. Work on attempting to resolve some of the security concerns is captured in http://cabforum.org/pipermail/validation , although the limited participation (largely of CAs) prevents a lot of the thorough analysis this work represents, and having a broader participation such as through secdispatch is better for the ecosystem as a whole.