Subject: [Acme] Validation Vulnerabilities

From: moparisthebest <[email-masked]>
Date: Fri, 05 Jun 2015 09:00:09 -0400

Hello all,

These vulnerabilities would allow an attacker who doesn't control a
domain to get a certificate for that domain, and are basically due to
problems with DNS.

Basically I noticed a comment here:
https://github.com/letsencrypt/boulder/issues/11#issuecomment-103897922
which says letsencrypt won't support DNS validation at the start
because of vulnerabilities, but the problem is all other forms of auth
(DVSNI/Simple HTTPS) also rely on the same DNS to look up the domain
name to connect to, and are therefore subject to the same vulnerabilitie
s.

The *correct* and only perfect solution to this is only allowing
DNSSEC signed responses for any of the above validation tests.  This
means that if a response is properly covered by DNSSEC, none of the
following hacks need to be applied.  But since we don't live in a
perfect world, I'll propose some things that attempt to work around
the issues without DNSSEC:

1. Only allowing DNS over TCP instead of UDP would prevent a
non-man-in-the-middle attacker from sending a well-timed UDP response
with a fake DNS record in it.
2. A man-in-the-middle could hijack DNS queries and send back whatever
responses they want, this could be at the datacenter, bandwidth
provider, or even a nation-state style attacker.  Here are some crazy
ideas to attempt to prevent this:

    a. Have the validator perform DNS queries from 2 different
providers in 2 different geographic locations with 2 different
backbones (via a secure channel between servers, ssh/vpn etc), and
fail if the response is not the same.  For example a server in china
and the usa would likely not have the same man-in-the-middle able to
forge both responses.
    b. Have the validator perform the DNS queries from the server
directly then over TOR, or maybe over TOR multiple times requesting a
different exit node each time, and if the same response isn't returned
each time then fail.
    c. Query different DNS providers over a secure protocol like
DNSCurve or something, and fail if responses are different, OpenDNS is
the only one I know of that supports this right now.

The catch with methods a-c though are they fail with a load-balanced,
geographic-specific, or round-robin DNS, but then maybe fancy large
setups like that don't need automatic certificates?  Or maybe instead
of failing if the IPs were different, you just perform whatever test
you were doing on each of the IPs and verify that it passes against
all IPs.

I don't know if these implementation details should be mentioned in
the ACME spec per-say, or if they should just be
implementation-specific like in boulder, but I feel the
vulnerabilities should be mentioned at the least if not work-around idea
s.

I cross-posted this from
https://github.com/letsencrypt/acme-spec/issues/131

Thanks,
moparisthebest

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 5 Jun 2015 15:40:31 +0000

FWIW, IMHO, and whatever other fla's are appropriate:

I think it makes sense to at least detail the attacks, since relying on DNS is one of the methods supported by ACME.

> https://github.com/letsencrypt/acme-spec/issues/131

Can the people who maintain this particular github repo, put up some notice in BIG BOLD FLASHING LETTERS that the proper place for discussion is on this mailing list?

Thanks.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Jun 2015 11:57:29 -0400

On Friday, June 5, 2015, Salz, Rich <[email-masked]> wrote:

> I think it makes sense to at least detail the attacks, since relying on
> DNS is one of the methods supported by ACME.

We should document these risks, but we should be clear that they're
inherent to non-authoritative identity verification -- including pretty
much everything that is done today (regardless of ACME).

> Can the people who maintain this particular github repo, put up some
> notice in BIG BOLD FLASHING LETTERS that the proper place for discussion is
> on this mailing list?

I would propose that one we adopt draft-ietf-, then we put on the
controls.  For now, it's just an individual draft.  But I agree that it is
more helpful to have stuff on the list.

--Richard

>
> Thanks.
>
> _______________________________________________
> Acme mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/acme
>