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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
