[getdns-users] client authentication

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Apr 10 20:06:09 UTC 2017


On Mon 2017-04-10 17:38:19 +0200, A. Schulze wrote:

> as a client I could now query a TLS aware Resolver via DNS-over-TLS. I could prove to talk to the right server by checking the pin.
>
> $ getdns_query -s yeti-ns.datev.net aaaa -l L -m -K 'pin-sha256="QFWn+jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg="' @2a00:e50:f15c:1000::2:53
> ...
> Response code was: GOOD. Status was: At least one response was returned
>
> So far so good. But from the resolver operators view I like to know "who is my client?"
> Usually resolver aren't run to serve anybody (like 8.8.8.8 does) but are limited to answer requests from a trusted network only.
> With TLS it may be an option to limit the service to clients presenting a certificate from my own CA.
> like in the "Webworld" where it's simply a client certificate based authentication+authorization.
>
> Does DNS-over-TLS offer a similar setup?

I strongly discourage the operators of DNS recursive resolvers from
implementing client authentication.

For TLS 1.2 and earlier (i.e. all formalized versions of TLS today) the
client certificate is visible in the clear over the network during the
handshake.  This exposes your client's individual location information
to any passive network monitor, which is not a good thing for a protocol
that is intended to enhance user privacy.

RFC 7858 (which specifies DNS-over-TLS) does not contemplate client
authentication at all, which i think is a fine thing.  If you were
limiting client connection on the basis of IP address, you can continue
to do so over TLS, right?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.getdnsapi.net/pipermail/users/attachments/20170410/35cea7d8/attachment.bin>


More information about the Users mailing list