Re: [Acme] On DNSSEC

[Viktor Dukhovni <[e-mail]>]

[ Better late than never? ]

> On Oct 29, 2015, at 2:09 PM, Hugo Landau <[e-mail]> wrote:
> 
> DNSSEC
> ------
> 
> Using DNSSEC for DNS lookups by ACME CAs removes a significant attack
> vector for domains which are DNSSEC-signed.

+1.  I too would like to suggest that ACME CAs not accept unvalidated
proof of possession for DNSSEC domains (I have a list 100k domains that
are DNSSEC signed, from an overall sample size of 5-6 million domains,
so DNSSEC deployment seems to be around 2% based on that sample).

For this to be secure, such domains might need to be restricted to
validated DNS-based proof of possession.  Email to "admin@" is not
nearly as well authenticated.

> DANE
> ----
> 
> 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.

This seems too strict.  Provided the *current* certificate matches
the TLSA records, it should be possible to obtain a new certificate,
for which the domain owner will then publish new TLSA records.

Of course if the TLSA record is "DANE-EE(3) SPKI(1) SHA2-256(1)" and
the certificate is being replaced without replacing the key, then the
new and old TLSA records will be the same.

There are already a few SMTP servers with DANE TLSA records and LE issued
certificates that will start to expire in February through March.  I am
waiting to see how the folks operating these sites will handle the automated
rotation of LE certs.  My guess is they'll end up with incorrect TLSA records,
and will have to swich to "3 1 1" and configure the LE certificate rotation
to not automatically update the key.  Of course "2 1 1" may be a better option
if the issuer public key is sufficiently stable.

> 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.

Not necessarily, if what is being checked is the current rather than
future certificate, but of course "3 1 1" is operationally much simpler
and what is recommended in RFC7671 Section 5.1.

> 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?

Some sites will use LE certificates only for SMTP and not HTTPS.  Which
means that "_443._tcp" is not the only relevant TLSA RRset.  But this
opens up the whole can of worms around the WebPKI and what its certificates
mean for services other than HTTPS.  For now we'll likely continue to ignore
this inconvenient truth.

-- 
	Viktor.