
Certificate Authority Authorization (CAA) Research Study - okket
https://caastudy.github.io/
======
aplorbust
Whomever controls DNS controls Web PKI. True or false?

Please explain your answer.

You may assume "controls DNS" means potential control over delivery or content
of unencrypted DNS packets, e.g. the operator of a parent nameserver, the
operator of an open resolver, a delegated authoritative nameserver (e.g.,
Cloudflare), someone else intercepting and modifying packets, etc.

Rephrased question: In what ways, if any, is Web PKI dependent on DNS?

~~~
bluejekyll
> control over delivery or content of unencrypted DNS packets

And thus we are back to asking for DNSSec. With DNSSec all Records are signed
with RRSIGs, and can be validated as being legitimate answers. Your client
needs to support validating these of course.

Now, there are a lot of people who don't like DNSSec, and I don't blame them.
It's a hot mess in terms of deployment, etc.

It feels like with CAA, TLSA, and other record types we're getting closer to
some of the security people want in DNS. We also now have a pretty decent RFC
for DNS over TLS, which provides privacy (where needed) in addition to the
signed records.

We should be able to come up with a solution to securing DNS by utilizing the
existing CA systems out there. Where we could sign zones, and verify them,
independent of the chain of DNSKEY to DS records all the way back to the root
(this would be different from the current DNSSec validation). I'm not aware of
any existing RFCs for something like this.

~~~
aplorbust
"> control over delivery or content of unencrypted DNS packets

And thus we are back to asking for DNSSec."

DNSSEC does not encrypt DNS packets.

(Nor does TLS encrypt UDP DNS packets _per packet_. It encrypts a TCP stream.)

Not interested in a debate over DNSSEC, but please note I used the word
"unencrypted" for a reason.

Not only can the contents of unencrypted packets be tampered with, but, if I
am not mistaken, djb has suggested DNSSEC signed RRs are still vulnerable to
forgery.

~~~
bluejekyll
DNS does not only operate over UDP, it also uses TCP.

> (Nor does TLS encrypt UDP DNS packets per packet. It encrypts a TCP stream.)

DNS over TLS is for TCP:
[https://tools.ietf.org/html/rfc7858](https://tools.ietf.org/html/rfc7858)

It is an encrypted private stream.

For UDP encryption over DTLS:
[https://tools.ietf.org/html/rfc8094](https://tools.ietf.org/html/rfc8094)

> Not interested in a debate over DNSSEC, but please note I used the word
> "unencrypted" for a reason.

If you want privacy you use DNS over TLS or DNSCrypt. If you want assurance
that the records can be trusted, the signatures are required. Because DNS
relies on so many intermediary nodes for caching, etc, you need both. You need
the RRSIG to validate that the zone actually created and manages that record.
If you don't want people snooping on your queries, then you need a secure
encrypted connection.

You need both.

> djb has suggested DNSSEC signed RRs are still vulnerable to forgery.

can you find that? I know he's very much against DNSSEC, but I haven't seen
comments on forgery specifically.

~~~
aplorbust
"You need both."

Me, personally?

I do not use shared caches.

I do not use local or remote caches.

Wrote own nonrecursive (i.e. no RD bit ever set) stub resolver.

As such, I have no use for DNSCrypt.

I use trusted sources for lists of authoritative servers I need. I store IP
addresses for those servers permanently and track changes in them, if any,
over time.

I have little interest in what ICANN certifies as a "valid" or "invalid" name.
DNSSEC therefore does not appeal to me.

IMO, better Web PKI could be focused on _IP addresses_ and user-generated
public keys (maybe combined with user-chosen "pet names"), something like SSH.
Instead it appears to be solely focused on _names issued by a third party_ and
certificates based on those names, also issued by a third party.

Probably "You need both" was a figure of speech. If so, pay no mind.

"can you find that?"

[http://cr.yp.to/talks/2016.12.08/slides-
djb-20161208-dnssec-...](http://cr.yp.to/talks/2016.12.08/slides-
djb-20161208-dnssec-a4.pdf) and other DNS talks on that page

Pages 11, 32.

------
Shoothe
Last time I checked Cloudflare had incomplete support for CAA (no issuewild or
flags).

OHV also mentioned they are working on it but that was half a year ago and so
nothing.

~~~
regecks
They definitely support issuewild now, but annoyingly will inject their own
extremely broad CAA records into your zone unless you go into a different UI
and hit "Disable Universal SSL" down the bottom of the page, even if you don't
use their proxy service. I tried submitting feedback about this but I assume
it got ignored by the support rep.

Not a huge fan of the CAA UI. I would prefer the option to enter the RRs in a
raw format (like TXT records), even if it's not the default UI.

~~~
Shoothe
That they generate certificates with my name was such a bewildering move (I
knew as I monitor CT logs). I had to contact support for them to stop as they
admitted there was no UI for that.

> Not a huge fan of the CAA UI. I would prefer the option to enter the RRs in
> a raw format (like TXT records), even if it's not the default UI.

Couldn't agree more. No SSHFP too. I'm waiting for OVH to add CAA records and
I migrate back to them.

