[liberationtech] RFC: comments on discovery mechanisms

[Jacob Appelbaum]

On 12/03/2010 03:39 PM, David-Sarah Hopwood wrote:
> On 2010-12-03 20:00, Jacob Appelbaum wrote:
>> On 12/03/2010 02:48 PM, David-Sarah Hopwood wrote:
>>> DNSSEC might prevent forgery, but cannot prevent blocking.
>>
>> This is my major point of frustration with DNSSEC. It is easy to provide
>> query privacy for clients and some important DNSSEC people don't
>> understand why this is important.
>>
>> My attempts to discuss this with DNSSEC people usually ends in
>> frustration. They see no point in privacy for a user's queries if they
>> intend to directly connect to the site. Of course if the site has TLS,
>> the game changes and DNSSEC becomes the weakest privacy link.
> 
> Whether the site has TLS makes little difference, since the domain name is
> in the clear in the TLS handshake -- both in the server_name extension if
> the client sends it (as most recent browsers do [*]), and in the server's
> certificate.

Yes, I'm well aware that the TLS handshake is also not privacy perfect.
I think that there should probably be a TLS server_name extension that
actually hashes or encrypts the hostname. It's rather frustrating that
in all of this that they didn't think to do that...

> 
> That's not to say it wouldn't be useful to put obstacles in the way of
> DNS-level blocking. Blocking at the DNS level is particularly cheap and
> easy; it can be done just by putting pressure on the domain registrar and
> without filtering individual connections. Similar blocking at the IP
> level without filtering individual connections would require manipulating
> routing tables, which is also not particularly difficult technically, but
> might be more difficult politically for some actors.
> 

Sure.

> I don't really see how DNSSEC with query privacy would help much in raising
> obstacles to DNS-level blocking, though. Am I missing something?

Yeah, it's not just about DNS-level blocking. Quite frustratingly, a lot
of large networks filter connections based on content of packets - this
might be a string in a DNS packet or it might be a string found
elsewhere in any other payload.

In a protocol where the name is otherwise entirely obfuscated, we lose
the ability to use DNS because of the lack of query privacy. TLS when
used as browsers use it isn't much better. However, if you're rolling
your own protocol, you can shove in something obfuscated into the
server_name extension - there is no such quick fix for the privacy
failures of DNSSEC.

All the best,
Jake