
CAA Adoption Notes - okket
https://gist.github.com/roycewilliams/1710ade469c05eb0b090d268470aa741
======
andrewstuart2
This definitely looks interesting, but I'm a bit disappointed this is intended
to be solely a CA-side check. I'd much rather specify with DNSSec a set of
root CA certificates that are trusted to sign certs for my domain, that the
browser could download and trust at the same time it resolves the hostname.
Perhaps with the limitation that they must be served (as specified for CAA)
via DNSSEC, and potentially by the DNS servers on the glue record. It should
be easy to use similar proofs of ownership to LetsEncrypt if that additional
level of trust is desired.

LetsEncrypt is awesome, but the rate limiting and some missing features can be
a bit of a buzzkill and require extra engineering to work around (e.g. reusing
FQDN by reverse proxying on path if you're, say, deploying one environment per
pull request). It's a nontrivial of work to make sure all your resources are
using relative URLs just so they can be mounted on any path on a reverse
proxy.

I'd much rather be able to specify my own Root CA on my DNS server and then
just let my Vault intermediate CA generate certs to its little heart's
content. No rate limiting, no '*' limitations, etc. And I wouldn't have to ask
my users to either accept my invalid cert manually each time (poor security),
trust each cert permanently (poor ux), or trust my CA cert for all domains
anywhere (a level of trust I'm not sure I'm comfortable with -- back to poor
security).

~~~
hdhzy
The usual argument against certs in DNS is that nameserver owners can quietly
issue valid certs.

You have national domain? Your government can transparently create valid cert
for your domain. For more details see
[https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

~~~
andrewstuart2
I think that would be fairly easy to create rules for, though. Only check at
the level where registrars are handing out domains (i.e. trust the most-
specific SOA, not counting TLD).

In fact, with LetsEncrypt or DV in general, I'm not sure what exists already
to stop the scenario you're referring to. My TLD can decide they want certs
for my domain and start advertising their nameservers to any IP addresses
owned by LetsEncrypt.

As it is there's plenty of manual checking that keeps CAs in check. I don't
see why the same processes couldn't be applied to such a system.

~~~
hdhzy
You can check that a new certificate was issued for your domain through
Certificate Transparency. Maybe if DANE/TLSA certs would also have be
submitted to CT logs and browsers required CT that'd provide stronger security
that we have now...

Another thing is DNSSEC's reliance on RSA 1024 (did that change?).

~~~
okket
You can absolutely use better keys than RSA 1024 for DNSSEC, see

[http://dnsviz.net/d/sys4.de/dnssec/](http://dnsviz.net/d/sys4.de/dnssec/)

It will take a while until everyone has upgraded, but so far no fast attack on
RSA 1024 has been reported...

Even elliptic curve algorithm based keys are possible now (and recommended
because of their small size, which is good for one packet UDP answers, which
is not possible with RSA 2048)

See ALG13 etc:

[https://www.iana.org/assignments/dns-sec-alg-numbers/dns-
sec...](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-
numbers.xhtml)

~~~
pfg
Other problems with DNSSEC aside, the crazy thing here is the suggestion to
replace the Web PKI with a system that has taken _longer_ to migrate towards
safe key sizes than the existing solution. 1024-bit keys for end-entity
certificates were deprecated in 2013 and the last 1024-bit roots were pulled
in 2014-2015 (ish?). I don't feel like the CA/B Forum is a particularly fast-
moving body, so this is pretty telling.

------
QUFB
Sad that Route 53 isn't on the supported list. It should really be called out
that Amazon isn't supporting this record type.

