Hi everyone,
I'm a Software Engineering master's student at TU Wien, Austria, with a recent focus on computer security and privacy issues. I am interested in participating in GSoC 2017, particularily in the task to support all kinds of DNS queries via Tor [1].
I've seen the mailing list discussions of 2012 and read the resulting proposition 219 [2]. What do you think, which parts of it (if any) would need to be adapted for DNS in 2017? My current impression is that not much has changed, particularily regarding DNSSEC support and deployment.
As of now, the proposal looks fairly complete with few questions remaining, the biggest research task being how to utilize libunbound for query/response parsing and construction. Implementing the RELAY DNS cells then seems fairly straightforward. Unit/integration tests and some fuzzing would be a good idea. The problem of reducing DNSSEC roundtrips (serialization) to be investigated in a later phase, I would say.
Is a separate AXFR tool still something that is desired? I have no experience with zone transfers -- can't the existing tooling just be used over a normal TCP conn through Tor?
This project idea would make a good match to my thesis in progress, for which I am researching and evaluating privacy-improving DNS tools in the context of Tor (DNSCrypt, DNS-over-TLS) [3], inspired by the awesome paper on DNS correlation [4]. For example, I recently built a SOCKS-to-SOCKS translator which allows to resolve hostnames using a resolver of choice, e.g. using DNSCrypt with TBB.
Looking forward to hearing your thoughts, concerns and opinions!
Best regards, Daniel
IRC handle on OFTC: idealchain
[1]: https://www.torproject.org/getinvolved/volunteer.html.en#supportAllDNS [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.tx... [3]: My work-in-progress mindmap about DNS Privacy (not related to prop219): https://drive.google.com/open?id=0B3d38csDsjwudDJOUjRleE93bjQ [4]: https://nymity.ch/dns-traffic-correlation/tor-dns.pdf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Daniel Achleitner:
Hi everyone,
I'm a Software Engineering master's student at TU Wien, Austria, with a recent focus on computer security and privacy issues. I am interested in participating in GSoC 2017, particularily in the task to support all kinds of DNS queries via Tor [1].
I've seen the mailing list discussions of 2012 and read the resulting proposition 219 [2]. What do you think, which parts of it (if any) would need to be adapted for DNS in 2017? My current impression is that not much has changed, particularily regarding DNSSEC support and deployment.
As of now, the proposal looks fairly complete with few questions remaining, the biggest research task being how to utilize libunbound for query/response parsing and construction. Implementing the RELAY DNS cells then seems fairly straightforward. Unit/integration tests and some fuzzing would be a good idea. The problem of reducing DNSSEC roundtrips (serialization) to be investigated in a later phase, I would say.
Is a separate AXFR tool still something that is desired? I have no experience with zone transfers -- can't the existing tooling just be used over a normal TCP conn through Tor?
This project idea would make a good match to my thesis in progress, for which I am researching and evaluating privacy-improving DNS tools in the context of Tor (DNSCrypt, DNS-over-TLS) [3], inspired by the awesome paper on DNS correlation [4]. For example, I recently built a SOCKS-to-SOCKS translator which allows to resolve hostnames using a resolver of choice, e.g. using DNSCrypt with TBB.
Looking forward to hearing your thoughts, concerns and opinions!
Best regards, Daniel
IRC handle on OFTC: idealchain
(Thinking out loud.) It would be interesting to have some kind of algorithm agility here. For example, a Tor client could send a request for a Namecoin domain name, and the exit relay would return a Namecoin merkle proof in the same way that it would return a DNSSEC signature if were a DNS doman name.
Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
On 2017-04-02 05:22, Jeremy Rand wrote:
(Thinking out loud.) It would be interesting to have some kind of algorithm agility here. For example, a Tor client could send a request for a Namecoin domain name, and the exit relay would return a Namecoin merkle proof in the same way that it would return a DNSSEC signature if were a DNS doman name.
It certainly seems to be a good idea to design the cell format to be agnostic as to what kind of "proof data" is attached to the DNS response. As prop219 just wraps around the existing DNS-packet wire-format, it should already allow that, provided that Namecoin has a wire-format for the proof.
Certainly out of scope for GSoC, but I'm wondering: Apart from running a full Namecoin node (and storing the whole blockchain) on every client/exit node/whatever, is there a privacy-preserving way to resolve a .bit domain, i.e. without an upstream node/resolver learning/logging exactly which domain was resolved?
Regards, Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Daniel Achleitner:
On 2017-04-02 05:22, Jeremy Rand wrote:
(Thinking out loud.) It would be interesting to have some kind of algorithm agility here. For example, a Tor client could send a request for a Namecoin domain name, and the exit relay would return a Namecoin merkle proof in the same way that it would return a DNSSEC signature if were a DNS doman name.
It certainly seems to be a good idea to design the cell format to be agnostic as to what kind of "proof data" is attached to the DNS response. As prop219 just wraps around the existing DNS-packet wire-format, it should already allow that, provided that Namecoin has a wire-format for the proof.
Awesome, that's great to hear. Namecoin doesn't have a "canonical" wire format for those proofs, but we have one implementation that made up a format for its own use (with the intention of standardizing later).
Certainly out of scope for GSoC, but I'm wondering: Apart from running a full Namecoin node (and storing the whole blockchain) on every client/exit node/whatever, is there a privacy-preserving way to resolve a .bit domain, i.e. without an upstream node/resolver learning/logging exactly which domain was resolved?
I can think of 3 ways.
(1) We have a client right now that only downloads the full blocks from the most recent year (which means it has all the transactions that correspond to unexpired names); it also downloads the block headers going back to the genesis block (so that it can verify PoW). This requires around 10 minutes to do initial sync, and around 400 MB of storage. This client generates no network traffic for lookups, so no one learns anything about what was resolved.
(2) It should be possible in theory to do a softfork that has a coinbase commitment to a merkle root of all the unexpired names and their values. This merkle tree could be constructed such that you could retrieve a subtree from another Namecoin node, and verify that all the names in that subtree are authentic, while not revealing to the node which name within that subtree you were looking up. (Choosing the tradeoff between subtree size and privacy is up to the user.)
(3) We could, hypothetically, hardfork to store only the hash of a name in the blockchain rather than the name itself. The value of the name could be encrypted with a key derived from the preimage of the hash. This would hide the name being looked up unless the node being queried already knew of a specific name or hash to be looking for.
I don't foresee (2) or (3) happening very soon, but maybe in the future.
Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
-
Daniel Achleitner -
Jeremy Rand