[getdns-users] client authentication

[Shumon Huque]

On Mon, Apr 10, 2017 at 6:30 PM, Christian Huitema <huitema at huitema.net>
wrote:
>
> 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> 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.
>

Although DNS over TLS might be enough of a green field application that
perhaps TLS 1.3 only out of the gate might be plausible if there were new
requirements.

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

Yeah, it's a bit challenging. One problem with the DNS level solution is
that the server is paying the full price of a TLS handshake before deciding
whether or not to allow access, which doesn't seem very desirable.

> But first, we have to be really convinced that we do need client auth!

Right!

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