DoH/DoT certificate pinning

[buffrr]

One issue with allowing users to trust a validating resolver over a secure channel is that the secure connection itself relies on WebPKI which takes away the advantages provided by DANE.

Pinning is typically not recommended by DoH providers as the public key of the certificate could change, which will eventually break clients' setup. Even though trusting a resolver to do the validation is not ideal or recommended it's still needed by some users that don't want to compile letsdane with unbound and don't have a validating resolver.

Maybe with DANE-TA(2) support (issue #10) we can allow pinning the CA of a DoH or DoT provider? The CA is less likely to change making the setup less brittle. The advantage of this is trusting a single CA used by the resolver instead of all CAs installed on the device.

Users still need to manually provide a TLSA record for the pinning (which can be optional)

[brandondees]

I think CA pinning is a sound idea, will a CAA record suffice for that?

so did i read correctly that will this still give users / resolvers the option of explicit individual cert pinning (e.g. for when i am managing my own personal infrastructure)?

[buffrr]

I think CA pinning is a sound idea, will a CAA record suffice for that?

These records are not suitable for pinning. They are mostly intended for public certificate authorities and aren't normally checked by clients (CAs query and check those records before issuing certificates). CAA records include issuer name not the hash or public key of a certificate.

so did i read correctly that will this still give users / resolvers the option of explicit individual cert pinning (e.g. for when i am managing my own personal infrastructure)?

when using a DNS over HTTPS resolver, a bootstrap TLSA record could be used to authenticate the TLS connection of the DoH resolver without relying on the traditional WebPKI:

If we use a TLSA record for this, users would be able to choose DANE-TA usage 2 to pin the CA for the resolver like this (not sure about the flag name yet):

$ letsdane -r https://1.1.1.1 -resolver-tlsa '2 1 1 7b4211cf94e2a37180d57b387d4556987d711c3887d9d31b56d0814a438876a3'

They can also pin an individual leaf certificate using DANE-EE usage 3:

$ letsdane -r https://1.1.1.1 -resolver-tlsa '3 1 1 a1df686ec7285d0343e7afc38a4ca966b2645c6bdb415e58eb54067dc362b47a'

it's a bit weird to create a TLSA record for 1.1.1.1 it uses TLS but it's an IP address.

DNS Stamps

Another solution is using dns stamps (also stamp calculator) it works with DoH, DoT and even Oblivious DoH. It encodes the resolver address and the certificate hash (along with other parameters) into a single string.

The stamp used in this example is for Cloudflare DoH (certificate hash is encoded as well):

$ letsdane -r sdns://AgcAAAAAAAAABzEuMC4wLjGgENk8mGSlIfMGXMOlIlCcKvq7AVgcrZxtjon911-ep0cg63Ul-I8NlFj4GplQGb_TTLiczclX57DvMV8Q-JdjgRgSZG5zLmNsb3VkZmxhcmUuY29tCi9kbnMtcXVlcnk

the nice thing about this solution is it doesn't add any extra flags and easy to copy as a single string. There is a list of public revolvers and their DNS stamps but any resolver can create their own stamp.

[brandondees]

thanks for clarifying

the stamp solution seems pretty nice. i'm wondering now why i hadn't heard of it before. is there some caveat other than it being less human readable?

[buffrr]

the stamp solution seems pretty nice. i'm wondering now why i hadn't heard of it before. is there some caveat other than it being less human readable?

It was made by the dnscrypt devs. The spec mentions that dnscloak, nextdns, adguard, and a few others support it. I think I've seen it in the dnscloak app but not sure about the others