On Sat 2015-03-07 18:09:27 -0800, Watson Ladd wrote:
> On Sat, Mar 7, 2015 at 10:43 AM, Phillip Hallam-Baker <[email protected]>
> wrote:
>> One hole that does raise privacy issues is Server Name Identification. If
>> you have 200 web sites on a server, you don't want to have to burn an IPv4
>> address for each one. So the DNS name of the server has to be passed in the
>> TLS handshake before the encryption tunnel is established. That is a privacy
>> hole.
>>
>> There are a few ways round this problem. But all the best ones involve
>> passing some sort of key from the DNS server. But to make those work cleanly
>> it is essential that TLS is layered on DNS and not the other way round.
>
> Huh? It's entirely possible to have bootstrapping: a preset public key
> to encrypt data to the resolver is used to establish the TLS
> connection over which DNS queries are made to retrieve the public keys
> needed for other servers.
I agree with Phillip that the SNI leakage of TLS is a privacy issue with
that protocol. But i don't think that it follows that we must not use
TLS for DPRIV. As Watson points out, a bootstrapping configuration
(something like an address and a public key for the server) is probably
the most sensible approach to configuring a sytsem to talk securely to a
resolver.
Once the client has this kind of bootstrapped info, using it to protect
a TLS handshake isn't particularly complicated.
This isn't to say that TLS is necessarily the right way to implement
DPRIV, but i don't think the SNI leakage of TLS is relevant to the
choice.
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
