<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 10, 2017 at 4:06 PM, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon 2017-04-10 17:38:19 +0200, A. Schulze wrote:<br>
<br>
> 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.<br>
><br>
> $ getdns_query -s <a href="http://yeti-ns.datev.net" rel="noreferrer" target="_blank">yeti-ns.datev.net</a> aaaa -l L -m -K 'pin-sha256="QFWn+<wbr>jgr2FfkRjCw8J77QJbChem3FUGwi9N<wbr>tp67SnVg="' @2a00:e50:f15c:1000::2:53<br>
> ...<br>
> Response code was: GOOD. Status was: At least one response was returned<br>
><br>
> So far so good. But from the resolver operators view I like to know "who is my client?"<br>
> 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.<br>
> With TLS it may be an option to limit the service to clients presenting a certificate from my own CA.<br>
> like in the "Webworld" where it's simply a client certificate based authentication+authorization.<br>
><br>
> Does DNS-over-TLS offer a similar setup?<br>
<br>
</span>I strongly discourage the operators of DNS recursive resolvers from<br>
implementing client authentication. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For TLS 1.2 and earlier (i.e. all formalized versions of TLS today) the<br>
client certificate is visible in the clear over the network during the<br>
handshake.  This exposes your client's individual location information<br>
to any passive network monitor, which is not a good thing for a protocol<br>
that is intended to enhance user privacy.<br></blockquote><div><br></div><div>Client authentication does not necessarily mean identifying a specific client </div><div>though - this authentication could use a group credential to provide  access </div><div>control to the DNS privacy server to that group, without needing to identify </div><div>specific clients or users. Perhaps someone wants to run a DNS over TLS </div><div>server for his/her set of colleagues all over the Internet, where access control</div><div>by IP address would not work. In TLS, this could be accomplished with </div><div>pre-shared key, shared raw public key, or even a shared client certificate </div><div>credential with a generic identity. This might also be possible via Transaction</div><div>Signature keys - at  the DNS layer, but that carries an additional per DNS</div><div>message overhead.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
RFC 7858 (which specifies DNS-over-TLS) does not contemplate client<br>
authentication at all, which i think is a fine thing.  If you were<br>
limiting client connection on the basis of IP address, you can continue<br>
to do so over TLS, right?<br></blockquote><div><br></div><div>I think I generally agree that per-client authentication and logging for DNS</div><div>privacy should not be recommended for all the reasons cited. But should</div><div>it be prohibited outright? I'm sympathetic to Christian's concerns that this</div><div>might rule out some folks who might have otherwise deployed DNS over</div><div>TLS. So if folks want to do it, perhaps we should examine what the best</div><div>methods are, and make sure those methods aren't leaking any client identities</div><div>in the clear. </div><div><br></div><div>Does TLS 1.3 protect the client certificate? To Christian's question about </div><div>alternatives to per-client certificate authentication in TLS, there are a few, but </div><div>they are unfortunately seldom used today (Pre-shared key; SRP; Kerberos - </div><div>spec deprecated; OpenPGP keys, etc). At the DNS layer, per-client authentication </div><div>is possible with GSS-TSIG, but it's very complex to set up.</div><div><br></div><div>-- </div><div>Shumon Huque</div><div><br></div></div></div></div>