Subject: [Acme] On DNSSEC

From: Hugo Landau <[email-masked]>
Date: Thu, 29 Oct 2015 18:09:38 +0000

So I was thinking about the use of DNSSEC with ACME.

There are two issues: Firstly, the use of DNSSEC in general (to perform
HTTP, DVSNI and DNS validation, looking for CAA records, etc.), and the
use of DANE.

DNSSEC
------

Using DNSSEC for DNS lookups by ACME CAs removes a significant attack
vector for domains which are DNSSEC-signed.

(Note that the effective use of DNSSEC requires the deployment of a validating
resolver within the CA's trusted environment. While organizations like
Google and Comcast have adopted DNSSEC in their public/for-customer
resolvers, this does not secure the client-recursive resolver link.
Software like Unbound can be used as a validating stub resolver and is
lightweight enough to be deployed on client systems, so validation could
be done on the same machine making validation callbacks if desired.)

It has already been pointed out that using UDP for DNS lookups is
vulnerable to packet spoofing, so where DNSSEC is not used, TCP should
be used for all lookups.

DANE
----

DANE attaches trust assertions to a given hostname, transport protocol
and port. However, an X.509 certificate attests a private key holder as
representing a set of domain names, not a set of (hostname, port)
tuples. Thus there is insufficient granularity to express the narrowness
of a DANE trust assertion in X.509 as practiced today.

Of course there is a precedent for the solution to this problem, already
squarely part of ACME; consider port 443 as being adequately
authoritative for the whole host, as practiced in the HTTP verification
method. Thus there seems to be little issue considering only _443._tcp
records. This is at least no worse than the practice today.

(By "hostname" I mean a DNS identifier of what is at least
assumed to be a single host, whereas by "domain name" I mean a service
identifier resolved to one or more hostnames. When SRV records are not
used, the hostname equals the domain name. Note that DANE requires that
its records be attached under hostnames, not domain names or next to SRV
records. Thus when SRV is used, the SRV records must also be signed.
But as _443._tcp can be standardised on and as SRV is very rarely used
with HTTPS, if at all, this seems like it can be safely ignored.)

Moving on, DANE expresses trust assertions using three option bytes, but
it's easier to describe its policy as several orthogonal axes:

  - Pinning vs. Affirmation. A DANE trust assertion can either pin
    certain certificates, thereby reducing the set of certificates which
    would be accepted for a connection to the given host to a strict
    subset, or it can nominate a certificate which would not
    conventionally have been accepted. I will arbitrarily call this
    'affirmation'. Note that affirmation implies pinning.

  - End Certificate vs. CA Certificate. A DANE trust assertion can
    either nominate an end certificate which must be used or a CA
    certificate which must appear in the certificate chain.

  - Public Key vs. Whole Certificate Matching. A DANE trust assertion
    can either match a given public key or a given certificate. Either
    way, the value matched will usually be expressed as a hash.

Where there are multiple TLSA records for a domain, validation is
'logical OR'; at least one must pass.

This leads to eight possibilities, but I think the general principle
that should be adopted is this: An ACME CA should not issue a
certificate if that certificate would not be valid under the TLSA
records currently present for the domain.

Whether pinning or affirmation is requested seems to be irrelevant for
the purposes of an ACME CA, as an ACME CA will presumably always
consider itself trustworthy and thus Pinning and Affirmation are
equivalent.

Since when a user requests a certificate from an ACME CA, the certificate
has not been issued yet, the use of (*, End Certificate, Whole
Certificate) is infeasible and would prevent any ACME CA from issuing a
certificate. (*, End Certificate, Public Key) can be used.

The use of (*, CA Certificate, *) can be used to pin to a desired ACME
CA; this would have an effect similar to a CAA record.

Overriding Nature of DNS Records
--------------------------------

It was previously mentioned that it may be desirable to require the
absence of DNS records in some circumstances, or to otherwise predicate
what validations may be performed on the contents of DNS.

Where TLSA records have been provisioned, this seems like a good case to
disable the use of HTTP, DVSNI or DNS TXT challenges.  Essentially, TLSA
should trump everything, assuming it is properly DNSSEC signed — or
perhaps even if it is not?

It may also be desirable to disable HTTP and DVSNI challenges when an
_acme-challenge DNS record exists for a domain, as this indicates an
intention and ability to authorize certificate issuance at the DNS
level. A CAA option could also be used; that would have the advantage of
also applying to all subdomains unless overridden.

Transparency & Logging
----------------------

DNSSEC or not, the DNS records retrieved for the purposes of a
validation should probably be logged. Where DNSSEC is used, logging the
records in the trust chain and/or the records used to securely determine
that a delegation is unsigned is desirable. (i.e. DNSKEY and DS records
and their covering RRSIGs, and NSEC/NSEC3 records and their covering
RRSIGs for unsigned domains)

I believe the trans WG has at least contemplated some form of DNSSEC
transparency by extending the Certificate Transparency system which
would be a nice addition, though it doesn't seem like it's going to
become a reality anytime soon.

Hugo Landau

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Oct 2015 17:50:49 -0800

On 10/29/15 10:09 AM, Hugo Landau wrote:

An interesting post in general, but to fill in one particular

> become a reality anytime soon.

It's something that's percolating along in the background.  We don't
yet have a draft that's mature enough to convince us that there's
something that can be done that would be useful, scales, and
demonstrates that problems around things like zone cuts can be solved,
but there's enough interest that it's likely something will happen.
It's going to be discussed briefly on Monday.

Melinda

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 29 Oct 2015 19:02:07 -0700

While DNSSEC could provide a security improvement for this use case, I
wonder how much overlap there is with the prospective audience of Let's
Encrypt and people who have DNSSEC deployed today...

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Oct 2015 03:08:23 +0000

I've been doing a bit of work with the .ie registry folks
on exactly this and would love to see a way to leverage
DNSSEC for acme.

It's early days (in terms of it being real) but we spoke
about it when the icann folks were in Dublin recently. [1]

And yes, the bit that'd glue dnssec and acme (in that case
LE) isn't there yet, but would be great.

S.

[1]
https://meetings.icann.org/en/dublin54/schedule/mon-tech/presentation-iencrypt-19oct15-en.pdf

On 30/10/15 02:02, Tony Arcieri wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Eric Mill <[email-masked]>
Date: Thu, 29 Oct 2015 23:22:59 -0400

> Encrypt and people who have DNSSEC deployed today...

Since the target audience is the CA, rather than subscribers, you could get
meaningful security improvements even without widespread populist adoption.
The CA would need to validate it, and the DNS providers of the subscribers
would need to support it. While some subscribers may operate their own DNS,
many will use common third party services.

While many third-party DNS providers do not support DNSSEC, there are some
who do[1][2], and perhaps some who could be incentivized to add it if they
knew there was meaningful CA use and validation of the records.

-- Eric

[1] https://blog.cloudflare.com/dnssec-is-open-for-beta/
[2] http://www.gandi.net/domain/dnssec

-- 
konklone.com | @konklone <https://twitter.com/konklone>