wiki:org/meetings/2019Stockholm/Notes/MeaningfulNamesForOnions

(AKA Paul's 2nd presentation on SAT domains)

Followup on SAT domain presentation. This will explore SAT domain properties and the properties of other tech.

Looking at:

  • SAT addresses
  • Onion Alt-Svc
  • HTTPS-Everywhere rewriting to .onion address
  • HTTPS-Everywhere rewriting to SAT address

Not really looked at, but mentioned:

  • Namecoin, OnioNS, etc.
  • Meaningful subdomain of onion address (inverse of SAT)

Onion Alt-Svc are NOT self-authenticating, like plain onions or SAT domains. The user is not supposed to know if they are going to the/a onion address. They don't know which they are using, if any.

This is web only. Don't currently support anything other than HTTP/S. If the protocol has a way to get the user the SAT signature, then SAT domains may work there too.

Q: What's the difference between receiving from a friend a SAT address and receiving an onion address? A: 1. Binding the friendly tranditional name to the onion address; can't forget

what site is behind this domain.

  1. SAT works for people who can't use onions

Q: Can SAT addresses really replace onion addresses? A: No

Q: This leaks to DNS your interest in an onion service. A: Yes.

Follow on from above answers ... this is for people who already have a site and want to set up a more secure version (potentially in the future allowing the Tor-enabled users to do onion lookups and stop leaking to DNS). Though the buy-in to actually running their site as onion service in addition to regular site is not required.

It's really important to dgoulet, Micah, and Will S. that (in the future when this is implemented) when Tor Browser goes to the onion directly instead of the SAT domain over the regular web that the SAT domain go to the web server in a "Host:" header. Especially Will. He said that when the Host header doesn't say facebook.com (or similar) it's really hard internally at Facebook.

Matt has been doing all the programming for this at NRL, but is moving to other stuff at NRL. Paul is looking for help at Tor Project, especially since this goes along with Sponsor 27. Tor should probably adopt these.

Perk of onion alt-svc: if they were to stop working all at once overnight, facebook.com will keep working.

Two problems with onion alt-svc:

  1. not self authenticating. already covered at the beginning.
  2. it facilitates tracking. TB only 1st party thanks to isolation, otherwise

tracking by 3rd parties too.

The paper we wrote on SAT domains is going to appear at IEEE SecDev. Final camera ready not out yet, but ask Paul for a copy and you'll get one.

Key rotation of the onion part of the SAT domain. If the site owner still has the old key, they can keep responding with the old SAT domain and direct people to the new one. The redirect could potentially be automatic in the software.

Key revokation of the onion part of the SAT domain. ... never elaborated.

Paul would like dev help from S27/Tor Project. George K. says Tor Browser team/Tor Project probably doesn't have time/moeny to help work on this. George suggested SAT domain stuff get worked on by an outside third party (like NRL) and at the last moment, give it to Tor to merge as appropriate.

Research that still needs to be done:

  • centralized list
  • tofu
  • something else

which of these is the way forward? how should it work?

Also user study type stuff. How should the GUI look?

Last modified 5 months ago Last modified on Jul 13, 2019, 10:56:40 AM