With proposal 227 in 0.2.6.3-alpha, we added a way for authorities to vote on e.g. the latest versions of the torbrowser package.
It appears we aren't actually using that, though. Are we planning to use it in the future?
On Fri, Jun 16, 2017 at 02:08:53PM -0400, Nick Mathewson wrote:
With proposal 227 in 0.2.6.3-alpha, we added a way for authorities to vote on e.g. the latest versions of the torbrowser package.
It appears we aren't actually using that, though. Are we planning to use it in the future?
Last I checked, the authority operators were uncomfortable with the slippery slope of "everybody who has some sort of package sends us their filename and checksums", because then every Tor client and relay fetches that text every hour forever, and we could imagine that blob of text growing out of hand.
That said, having the directory authorities vote about a checksum of a file, and that file contains all the things, and somebody else coordinates what goes in that file, how to handle name spaces in it, etc, sounds like it could be totally doable.
That said, from the directory authority perspective, we would want to automate the process of voting about that file -- not have the authority operators manually check the file and change the sha256 every time somebody updates it.
For example, we could wget the file and then put the checksum into our votes, thus giving some sort of primitive perspective-access-network style robustness.
I don't know what this approach would do to the security assumptions from that proposal though.
--Roger
On 16 June 2017 at 13:15, Roger Dingledine arma@mit.edu wrote:
On Fri, Jun 16, 2017 at 02:08:53PM -0400, Nick Mathewson wrote:
With proposal 227 in 0.2.6.3-alpha, we added a way for authorities to vote on e.g. the latest versions of the torbrowser package.
It appears we aren't actually using that, though. Are we planning to use it in the future?
Last I checked, the authority operators were uncomfortable with the slippery slope of "everybody who has some sort of package sends us their filename and checksums", because then every Tor client and relay fetches that text every hour forever, and we could imagine that blob of text growing out of hand.
That said, having the directory authorities vote about a checksum of a file, and that file contains all the things, and somebody else coordinates what goes in that file, how to handle name spaces in it, etc, sounds like it could be totally doable.
That said, from the directory authority perspective, we would want to automate the process of voting about that file -- not have the authority operators manually check the file and change the sha256 every time somebody updates it.
For example, we could wget the file and then put the checksum into our votes, thus giving some sort of primitive perspective-access-network style robustness.
I don't know what this approach would do to the security assumptions from that proposal though.
This sounds like the right approach is a transparency log - the authorities include a single hash; and it's the responsibility of all interested packagers to put their submissions in the log...
-tom
On 16 June 2017 at 13:15, Roger Dingledine arma@mit.edu wrote:
On Fri, Jun 16, 2017 at 02:08:53PM -0400, Nick Mathewson wrote:
With proposal 227 in 0.2.6.3-alpha, we added a way for authorities to vote on e.g. the latest versions of the torbrowser package.
It appears we aren't actually using that, though. Are we planning to use it in the future?
Last I checked, the authority operators were uncomfortable with the slippery slope of "everybody who has some sort of package sends us their filename and checksums", because then every Tor client and relay fetches that text every hour forever, and we could imagine that blob of text growing out of hand.
That said, having the directory authorities vote about a checksum of a file, and that file contains all the things, and somebody else coordinates what goes in that file, how to handle name spaces in it, etc, sounds like it could be totally doable.
That said, from the directory authority perspective, we would want to automate the process of voting about that file -- not have the authority operators manually check the file and change the sha256 every time somebody updates it.
For example, we could wget the file and then put the checksum into our votes, thus giving some sort of primitive perspective-access-network style robustness.
I don't know what this approach would do to the security assumptions from that proposal though.
--Roger
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Nick Mathewson:
With proposal 227 in 0.2.6.3-alpha, we added a way for authorities to vote on e.g. the latest versions of the torbrowser package.
It appears we aren't actually using that, though. Are we planning to use it in the future?
It might be a candidate for update hardening, e.g. in the Tor Browser case. Note, though, that there are a bunch of issues with the Tor Browser side of the proposal (https://trac.torproject.org/projects/tor/ticket/14676#comment:1). We'd need to solve those first before starting any implementation. I guess this could be a nice item for a funding proposal if we think that's the way to do the update hardening.
Georg
-
Georg Koppen -
Nick Mathewson -
Roger Dingledine -
Tom Ritter