[getdns-users] client authentication

[Shumon Huque]

On Mon, Apr 10, 2017 at 4:06 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

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

Client authentication does not necessarily mean identifying a specific
client
though - this authentication could use a group credential to provide
 access
control to the DNS privacy server to that group, without needing to
identify
specific clients or users. Perhaps someone wants to run a DNS over TLS
server for his/her set of colleagues all over the Internet, where access
control
by IP address would not work. In TLS, this could be accomplished with
pre-shared key, shared raw public key, or even a shared client certificate
credential with a generic identity. This might also be possible via
Transaction
Signature keys - at  the DNS layer, but that carries an additional per DNS
message overhead.


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

I think I generally agree that per-client authentication and logging for DNS
privacy should not be recommended for all the reasons cited. But should
it be prohibited outright? I'm sympathetic to Christian's concerns that this
might rule out some folks who might have otherwise deployed DNS over
TLS. So if folks want to do it, perhaps we should examine what the best
methods are, and make sure those methods aren't leaking any client
identities
in the clear.

Does TLS 1.3 protect the client certificate? To Christian's question about
alternatives to per-client certificate authentication in TLS, there are a
few, but
they are unfortunately seldom used today (Pre-shared key; SRP; Kerberos -
spec deprecated; OpenPGP keys, etc). At the DNS layer, per-client
authentication
is possible with GSS-TSIG, but it's very complex to set up.

-- 
Shumon Huque
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/users/attachments/20170410/499d6d8c/attachment.htm>