[getdns-users] client authentication

[Christian Huitema]

On 4/10/2017 1:38 PM, Shumon Huque wrote:
> On Mon, Apr 10, 2017 at 4:06 PM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net <mailto:dkg at fifthhorseman.net>> wrote:
>
>     ...
>
>
>     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.
>

Yes. That's why TLS client authentication is probably a bad idea. The
identity leak is kinda fixed in TLS 1.3, but only if the client refuses
to negotiate down to 1.2, and that's not practical.

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

Pretty much all the TLS client authentication schemes share the
"identity leak in clear text" issue that DKG is mentioning. If we really
need client auth, we need to look at a DNS level solution, or maybe DNS
over TLS specific solution. If GSS-TSIG works, that may be it. If it
doesn't, maybe use something else, like some TBD EDNS transaction. But
first, we have to be really convinced that we do need client auth!

-- Christian Huitema
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://getdnsapi.net/pipermail/users/attachments/20170410/9353c628/attachment.html>