Re: [tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification

On 25 Apr (13:02:28), Q Misell via tor-dev wrote: > Hi all, > > I've spent some time working on ACME for Tor hidden services (you may have > seen discussion of this work on the onion-advisors mailing list). Full > details of the project are available at https://e.as207960.net/w4bdyj/AX8Ffqsd > >

Re: [tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

On 24 Jan (09:05:18), Nick Mathewson wrote: > On Tue, Jan 24, 2023 at 9:02 AM David Goulet wrote: > > > On 23 Jan (13:31:49), Nick Mathewson wrote: > > > On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson > > wrote: > > > > > > > ``` > > &

Re: [tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

On 23 Jan (13:31:49), Nick Mathewson wrote: > On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson wrote: > > > ``` > > Filename: 342-decouple-hs-interval.md > > Title: Decoupling hs_interval and SRV lifetime > > Author: Nick Mathewson > > Created: 9 January 2023 > > Status: Draft > > ``` > > > > #

Re: [tor-dev] Latest releases missing from changelog

On 09 Nov (12:04:07), Michael Rogers wrote: > Hi all, > > The latest releases (0.4.7.10, 0.4.6.12 and 0.4.5.14) seem to be missing > from the changelog: > > https://gitlab.torproject.org/tpo/core/tor/-/raw/main/ChangeLog > > Is this file still the right place to look? Good catch. I just pushed

Re: [tor-dev] Counting HS descriptor uploads

On 28 Jun (13:27:03), Michael Rogers wrote: > Hi, Better late than never I guess :S... > > The Briar team is working on a new app that uses Tor hidden services, and > we're trying to work out when the server publishing a hidden service should > consider the service to be reachable by clients. >

[tor-dev] Network Team - New Support and Release Policy

Greetings everyone! This is, for now, the last policy change from the network team after the Deprecating C Patches policy from couple days ago[0]. However, this one has a bit more impact especially on the relay operators and thus the network. We are changing the C-tor support and release policy

[tor-dev] Network Team - Deprecating C-tor Patches

Greetings everyone! The network team has come up with a policy about C-tor patches in order to help and facilitate our transition to arti. The TL;DR is essentially that we will be reducing considerably the amount of patches (fixes and features) we take in for C-tor[0], most importantly on the

Re: [tor-dev] Discussion about Tor Directory Authority Consensus Code

On 26 Apr (15:19:26), Zhongtang Luo wrote: > Hi all! > > I am a PhD student currently doing some experiments on Tor. My advisor and > I was wondering if we can talk to somebody who takes care of the Tor > Directory Authority code, since there is a conceptual issue we wish to > communicate with

Re: [tor-dev] Time interval for changing Introduction Points in Tor Hidden Services

On 23 Mar (09:57:50), Piyush Kumar Sharma wrote: > Thank you David for the prompt reply. The information you provide is > helpful. > > I would also like to ask one more question related to HSDIRs. > From what I understand from the onion service v3 specification, the HSDIRs > corresponding to a

Re: [tor-dev] Time interval for changing Introduction Points in Tor Hidden Services

On 16 Mar (00:16:19), Piyush Kumar Sharma wrote: > Hi all, > > I have been investigating the Tor hidden services for some research work. > > I am finding it hard to obtain information about how often do Introduction > Points of hidden service change. > > More specifically, I am looking for

Re: [tor-dev] Accessing Shared Random Values as a Protocol on top of Tor

On 29 Oct (23:56:07), Sebastian Hoffmann wrote: > Hi, > > I'm wondering if I can access the shared random value[1] while > developing a > protocol/application on top of Tor onion services. The application is > still in > early development, but it would be great if I could depend on the shared >

Re: [tor-dev] proposal 328 status

On 01 Nov (20:46:05), nusenu wrote: > > > David Goulet: > > On 29 Oct (22:48:53), nusenu wrote: > > > Hi, > > > > > > I'm wondering if the current version of the text is the latest available > > > version of it or > > > if th

Re: [tor-dev] proposal 328 status

On 29 Oct (22:48:53), nusenu wrote: > Hi, > > I'm wondering if the current version of the text is the latest available > version of it or > if there is somewhere a newer version that hasn't been pushed yet? > >

Re: [tor-dev] A Simple Web of Trust for Tor Relay Operator IDs

On 03 Oct (18:16:05), nusenu wrote: > Hi, > > I wrote down a spec for a simple web of trust > for relay operator IDs: > >

Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only

On 14 Sep (11:31:02), Neel Chauhan wrote: > Hi Roger, Hi Neel! Thanks for your proposal!! > > On 2021-09-12 20:48, Roger Dingledine wrote: > > On Sun, Sep 12, 2021 at 12:17:37PM -0700, Neel Chauhan wrote: > > > If a relay has the MiddleOnly flag, we do not allow it to be used > > > for the >

Re: [tor-dev] Weaving a Faster Tor: paper/video of possible interest

On 20 Jul (01:29:54), Steven Engler wrote: > On 2021-07-19 3:24 p.m., David Goulet wrote: > > On 06 Jul (13:52:50), Ian Goldberg wrote: > > > Hello tor-dev, > > > > > > Steve Engler (currently part of the Shadow team) and I have a paper of > > > possib

Re: [tor-dev] Weaving a Faster Tor: paper/video of possible interest

On 06 Jul (13:52:50), Ian Goldberg wrote: > Hello tor-dev, > > Steve Engler (currently part of the Shadow team) and I have a paper of > possible interest to appear at ARES 2021 next month. > > It's a design of a multi-threaded relay architecture, of possible > particular interest when

Re: [tor-dev] descriptor sync finished event after disabling UseMicrodescritors

On 07 May (14:11:14), nusenu wrote: > Hi, > > what is the best way to find out when descriptor fetching is completed I wasn't entirely sure of this so I looked at the code and turns out that when you get new microdescriptors, we only emit a BOOTSTRAP event but if the bootstrap is already 100%,

Re: [tor-dev] ClientAuthV3 for v3 onions via Tor controller is accepted by ADD_ONION but seems to get ignored

On 04 May (06:59:39), Miguel Jacq wrote: > Hello again, just to add some clarification to what I realise is a confusing > output below: > > On Mon, May 03, 2021 at 04:38:07PM +1000, Miguel Jacq wrote: > > ``` > > user@onionshare:~$ sudo telnet localhost 9051 > > Trying ::1... > > Trying

Re: [tor-dev] Question about hidden services shared by multiple hosts

On 26 Mar (08:55:54), Holmes Wilson wrote: > Hi everyone, Greetings, > > We’re working on a peer-to-peer group chat app where peers connect over v3 > onion addresses. > > One issue are groups where there are many users but only a few are online in > a given moment. Onion addresses are

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

On 02 Mar (20:58:43), Mike Perry wrote: > > > On 3/2/21 6:01 PM, George Kadianakis wrote: > > > > David Goulet writes: > > > >> Greetings, > >> > >> Attached is a proposal from Mike Perry and I. Merge requsest is here: > >> >

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

On 09 Dec (11:36:09), Jim Newsome wrote: > > On 12/7/20 14:06, David Goulet wrote: > > Greetings, > > > > Attached is a proposal from Mike Perry and I. Merge requsest is here: > > > > https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 > >

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

On 07 Dec (15:36:53), Ian Goldberg wrote: > On Mon, Dec 07, 2020 at 03:06:43PM -0500, David Goulet wrote: > > Greetings, > > > > Attached is a proposal from Mike Perry and I. Merge requsest is here: > > > > https://gitlab.torproject.org/tpo/core/torspec/-/

[tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

They Are Overloaded Author: David Goulet, Mike Perry Created: November 3rd 2020 Status: Draft ``` # 0. Introduction Many relays are likely sometimes under heavy load in terms of memory, CPU or network resources which in turns diminishes their ability to efficiently relay data through the network. Having

Re: [tor-dev] proposal for "tor-relay" well-known URI

On 14 Aug (12:17:50), nusenu wrote: > Hi, > > I'm submitting this as a proposal according to: > https://github.com/torproject/torspec/blob/master/proposals/001-process.txt > > I made a PR request for you: > https://github.com/torproject/torspec/pull/129/files Thanks nusenu! FYI, the merge

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

On 22 Jun (17:52:44), George Kadianakis wrote: > Hello there, > > here is another round of PoW revisions: > https://github.com/asn-d6/torspec/tree/pow-over-intro > I'm inlining the full proposal in the end of this email. > > Here is a changelog: > - Actually used tevador's EquiX scheme as

Re: [tor-dev] Onion Service v2 Deprecation Timeline

On 15 Jun (12:34:17), David Goulet wrote: > This effectively means that from _today_ (June 11th 2020), the Internet has > around 15 months to migrate from v2 to v3 once and for all. Typo: June 11th 2020 --> June 15th 2020 :) David -- 262Gy/4o+HGG/7ELoDp1drRojN33l7AZaBoRHN6mjXY= sign

[tor-dev] Onion Service v2 Deprecation Timeline

Greetings everyone! I will try to make this quick. Deprecation of v2 has already been discussed on this list [0] and so this is not about re-creating this discussion but rather giving you the Tor Project timeline for v2 deprecation. To very quickly summarize why we are deprecating, in one word:

Re: [tor-dev] Moving key material out of the main tor process

On 20 May (17:45:51), Linus Nordberg wrote: > Hi, Greeting Linus! > > tl;dr How to move key material out of tor? > > ## The idea of a vault component > > ahf and others in the network team have been discussing the > possibility of a "vault" component in tor, for moving private keys out > of

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

On 19 May (13:55:37), Nick Mathewson wrote: > On Wed, May 13, 2020 at 10:09 AM David Goulet wrote: > > > > On 11 May (16:47:53), Nick Mathewson wrote: [snip] > > So thus, I personally will argue that moving v2 to ntor is really not the > > right thing to do. Onion se

Re: [tor-dev] Deprecating Tor Protocol Versions

On 15 May (13:58:06), teor wrote: > Hi all, > > Nick and I were talking about how we remove legacy features in tor, > and their corresponding subprotocol versions. > > Here is a list of the current subprotocol versions: > https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2049 > >

Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

On 26 Apr (19:37:56), Christian Hofer wrote: > Hi there, Greetings Christian! > > I have a proposal regarding DNS name resolution. > > Ticket: https://trac.torproject.org/projects/tor/ticket/34004 > Proposal: >

Re: [tor-dev] Proposal 319: RELAY_FRAGMENT cells

On 11 May (16:47:24), Nick Mathewson wrote: > ``` > Filename: 319-wide-everything.md > Title: RELAY_FRAGMENT cells > Author: Nick Mathewson > Created: 11 May 2020 > Status: Open > ``` > > (This proposal is part of the Walking Onions spec project.) > > # Introduction > > Proposal 249 described a

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

On 11 May (16:47:53), Nick Mathewson wrote: Hello! > ``` > Filename: 320-tap-out-again.md > Title: Removing TAP usage from v2 onion services > Author: Nick Mathewson > Created: 11 May 2020 > Status: Open > ``` > > (This proposal is part of the Walking Onions spec project. It updates > proposal

Re: [tor-dev] Does a design document for the DoS subsystem exist?

On 15 Apr (00:25:11), Lennart Oldenburg wrote: > Hello George, hello all, Hi Lennart, Sorry for the late reply, as you may have seen, things got a bit intense in Tor in the last 2 weeks. > > Thank you very much for the provided pointers. Great to hear progress is > being made on the Onion

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

On 06 Apr (17:08:12), Mike Perry wrote: [snip] > > I think you'll be bound by the amount of data a connection inbuf can take > > which has an upper bound of 32 cells each read event. > > > > Then tor will have to empty at once the inbuf, queue all INTRODUCE2 cells > > (at > > most 32) in that

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

On 02 Apr (18:54:59), George Kadianakis wrote: > Hello list, > > hope everyone is safe and doing well! > > I present you an initial draft of a proposal on PoW-based defences for > onion services under DoS. > > The proposal is not finished yet and it needs tuning and fixing. There > are many

Re: [tor-dev] CVE-2020-8516 Hidden Service deanonymization

On 04 Feb (19:03:38), juanjo wrote: Greetings! > Since no one is posting it here and talking about it, I will post it. > > https://nvd.nist.gov/vuln/detail/CVE-2020-8516 > > The guy: > http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html > > Is this real?

Re: [tor-dev] Evaluating rendezvous circuit build up CPU usage

On 13 Jan (13:39:37), Valentin Franck wrote: > Hello tor-devs, Hi Valentin! > > I am currently working on a DoS mitigation system aiming to protect the > availability of onion services flooded with INTRO2 cells. My idea is > using a (Privacy Pass like) token based approach as suggested in >

[tor-dev] Adding Tracing to little-t tor

Greetings tor-dev! This email is a discussion on adding tracing to little-t tor. Tracing can be a very abstract notion sometimes so I'll start with a quick overview of what that is, what we can achieve and use cases within tor. Then I'll go over a last point which is safety. This email doesn't

Re: [tor-dev] Practracker regen in #30381

On 27 Nov (10:50:50), teor wrote: > Hi George, David, > > It looks like you regenerated the whole practracker file in #30381: > https://trac.torproject.org/projects/tor/ticket/30381 >

[tor-dev] Onion Service Intro Point Retry Behavior

Greetings everyone, After some discussions between arma, mikeperry, asn and I, it is time for a famous tor-dev@ email thread to try to get to a consensus if need be. In the past weeks, a set of HSv3 reachability issues have been found regarding *service* intro points (IP): - hs-v3: Service

Re: [tor-dev] Optimistic SOCKS Data

On 08 Oct (19:49:34), Matthew Finkel wrote: > On Wed, Oct 2, 2019 at 5:46 PM Nick Mathewson wrote: > > > > On Fri, Sep 27, 2019 at 1:35 PM Tom Ritter wrote: > > > > > > On Mon, 5 Aug 2019 at 18:33, Tom Ritter wrote: > > > > > > > > On Tue, 2 Jul 2019 at 09:23, Tom Ritter wrote: > > > > > Or...

[tor-dev] [prop305] Introduction Point Behavior

Greetings, This is part of the many discussions about proposal 305 which is the ESTABLISH_INTRO DoS defenses cell extension. Implementation is close to done and under review in ticket #30924. However, there is one part that is yet to be cleared out. asn and I thought it would be better to bring

[tor-dev] Proposal 306: Onion Balance Support for Onion Service v3

Greetings! Around 4 months ago, nickm published a proposal draft for OnionBalance to support onion services v3. Due to #29583, it turns out that we can afterall take the easy approach which is basically how OnionBalance is working today for v2 but transposed to v3. See the ticket for the reasons

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

On 30 May (09:49:26), David Goulet wrote: > Greetings! [snip] Hi everyone, I'm writing here to update on where we are about the introduction rate limiting at the intro point feature. The branch of #15516 (https://trac.torproject.org/15516) is ready to be merged upstream which impleme

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

On 12 Jun (08:18:33), David Goulet wrote: After some days on tor-dev@ and a round of review, this is now a Draft in tor-spec.txt. https://gitweb.torproject.org/torspec.git/tree/proposals/305-establish-intro-dos-defense-extention.txt Cheers! David > Filename: 305-establish-intro-dos-defe

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

On 13 Jun (10:35:34), teor wrote: > Hi, [snip] > >> The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values > >> (uint64_t). It MUST match the specified limit for the following > >> PARAM_TYPE: > >> > >> [01] -- Min: 0, Max: INT_MAX > >> [02] -- Min: 0, Max: INT_MAX >

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

On 12 Jun (15:39:55), George Kadianakis wrote: > David Goulet writes: > > > Filename: 305-establish-intro-dos-defense-extention.txt > > Title: ESTABLISH_INTRO Cell DoS Defense Extension > > Author: David Goulet, George Kadianakis > > Created: 06-June-2019 >

[tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

Filename: 305-establish-intro-dos-defense-extention.txt Title: ESTABLISH_INTRO Cell DoS Defense Extension Author: David Goulet, George Kadianakis Created: 06-June-2019 Status: Draft 0. Abstract We propose introducing a new cell extension to the onion service version 3 ESTABLISH_INTRO cell

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

On 06 Jun (20:03:52), George Kadianakis wrote: > David Goulet writes: > > > Greetings! > > > > > > > > Hello, I'm here to brainstorm about this suggested feature. I don't have > a precise plan forward here, so I'm just talking. > > > Un

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

On 31 May (00:46:56), teor wrote: > Hi, > > > On 30 May 2019, at 23:49, David Goulet wrote: > > > > Over the normal 3 intro points a service has, it means 150 introduction > > per-second are allowed with a burst of 600 in total. Or in other words, 150 > >

[tor-dev] Onion Service - Intropoint DoS Defenses

Greetings! As some of you know, a bunch of onion services were or are still under heavy DDoS on the network. More specifically, they are bombarded with introduction requests (INTRODUCE2 cells) which forces them to rendezvous for each of them by creating a ton of circuits. This basically leads to

[tor-dev] Proposal 304: Extending SOCKS5 Onion Service Error Codes

Filename: 304-socks5-extending-hs-error-codes.txt Title: Extending SOCKS5 Onion Service Error Codes Author: David Goulet, George Kadianakis Created: 22-May-2019 Status: Open Note: We are extending SOCKS5 here but in terms, when Tor Browser supports HTTPCONNECT, we should not do

Re: [tor-dev] Proposal 303: When and how to remove support for protocol versions

On 22 May (18:57:06), Mike Perry wrote: > Nick Mathewson: > > Filename: 303-protover-removal-policy.txt > > Title: When and how to remove support for protocol versions > > Author: Nick Mathewson > > Created: 21 May 2019 > > Status: Draft > > > > 1. Background > > > >With proposal 264, added

Re: [tor-dev] Proposal 302: Hiding onion service clients using WTF-PAD

On 16 May (14:20:05), George Kadianakis wrote: Hello! > 4.1. A dive into general circuit construction sequences [CIRCCONSTRUCTION] > >In this section we give an overview of how circuit construction looks like >to a network or guard-level adversary. We use this knowledge to make the >

Re: [tor-dev] Network Health Monitoring

On 08 May (13:27:31), Iain Learmonth wrote: > Hi All, > > I'm working on #28322 to improve the monitoring of Tor Metrics services, > but this also has the side effect of monitoring network health. For > example, we'd like to know when Onionoo messes up and starts reporting > zero relays, but we

Re: [tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

On 06 May (18:19:58), George Kadianakis wrote: > Hello list, > > here is a control spec patch for adding v3 client auth commands to > add/remove/view clients from the client-side (so Tor Browser -> Tor): > >

Re: [tor-dev] Support for clients using shutdown(SHUT_WR)

On 10 Apr (14:27:06), Rob Jansen wrote: Greetings Rob! > Is there any plan to support shutdown(SHUT_WR) using RELAY_FIN cells now > that Tor is itself using shutdown()? (I didn't see any tickets about it > after a brief search.) It is not implemented and there are no open proposals so the quick

Re: [tor-dev] tor relay process health data for operators (controlport)

On 03 Feb (00:24:00), nusenu wrote: > Hi, Hello nusenu, Thanks for this email. I exporting more metrics on the control port is a great idea. I wanted to have that for a while so quite happy you started rolling the ball :). There are safety questions to ask ourselves here before blindly

Re: [tor-dev] OnionShare bug that's possibly caused by an upstream v3 onion bug

On 24 Nov (21:30:16), Micah Lee wrote: [snip] Greetings Micah! > But with v3 onion services, as soon as the OnionShare web server finishes > sending the full HTTP response, the torified HTTP client stops downloading. > I made a small python script, onion-bug.py, that reproduces the issue that >

Re: [tor-dev] Add EVENT message to pt-spec.txt and control-spec.txt

s correctly. You sure you don't want to switch to .txt file in the proposal/. Seems PDF are hard to review on Github? ... Cheers! David > > Great work, and I look forward to working with you to get this useful > functionality for all transports and transport-enabled applications! &

[tor-dev] Add EVENT message to pt-spec.txt and control-spec.txt

Greetings tor-dev! We've been working on improving PT reporting towards Tor so for instance Tor Browser can better inform the user or take actions based on the PT state when connecting to the network. The following ticket summarize it: https://trac.torproject.org/projects/tor/ticket/28180 To

Re: [tor-dev] HS v3 client authorization types

On 12 Jul (20:24:54), George Kadianakis wrote: > David Goulet writes: > > > On 18 May (19:03:09), George Kadianakis wrote: > >> Ian Goldberg writes: > >> > >> > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote: > >>

Re: [tor-dev] HS v3 client authorization types

On 18 May (19:03:09), George Kadianakis wrote: > Ian Goldberg writes: > > > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote: > >> On 05/09/2018 03:50 PM, George Kadianakis wrote: > >> > b) We might also want to look into XEdDSA and see if we can potentially > >> >use the

Re: [tor-dev] onion v2 deprecation plan?

On 28 Apr (09:34:09), teor wrote: > > On 28 Apr 2018, at 04:48, Damian Johnson wrote: > > >> OnionBalance requires STEM support for V3 > > > > Hi Alec, would you mind clarifying what you need from Stem? As far as > > I'm aware Stem supports v3 onion service creation... >

Re: [tor-dev] Setting NumEntryGuards=2

On 22 Mar (17:13:40), Mike Perry wrote: > David Goulet: > > On 22 Mar (13:46:36), George Kadianakis wrote: > > > Mike Perry <mikepe...@torproject.org> writes: > > > > > > > Arguments in favor of switching to two entry guards: > > > > > &

Re: [tor-dev] Setting NumEntryGuards=2

On 22 Mar (13:46:36), George Kadianakis wrote: > Mike Perry writes: > > > [ text/plain ] > > Back in 2014, Tor moved from three guard nodes to one guard node: > > https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters > >

Re: [tor-dev] Enhancement for Tor 0.3.4.x

On 12 Feb (14:32:41), David Goulet wrote: > Hello everone! > > As an effort to better organize our 0.3.4.x release for which the merge window > opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that > we want so we can better prioritize the development d

[tor-dev] Enhancement for Tor 0.3.4.x

Hello everone! As an effort to better organize our 0.3.4.x release for which the merge window opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that we want so we can better prioritize the development during the merge window timeframe (3 months). Each feature should have

Re: [tor-dev] monitoring significant drops of flags in dirauth votes

On 11 Feb (21:21:00), nusenu wrote: > > Thanks nusenu! Nice idea, added it to DocTor... > > thanks for implementing the new check so fast. > > > https://gitweb.torproject.org/doctor.git/commit/?id=8945013 > > > > It gives a notice if flags issued by an authority are 50% different > > from the

Re: [tor-dev] stem support for v3 ephemeral onion services

On 25 Jan (08:10:00), David Goulet wrote: > On 25 Jan (06:50:30), teor wrote: > > > > > On 25 Jan 2018, at 05:14, Micah Lee <mi...@micahflee.com> wrote: > > > > > > Now that Tor Browser 7.5 is released and includes the tor 0.3.2 series, > > &g

Re: [tor-dev] stem support for v3 ephemeral onion services

On 25 Jan (06:50:30), teor wrote: > > > On 25 Jan 2018, at 05:14, Micah Lee wrote: > > > > Now that Tor Browser 7.5 is released and includes the tor 0.3.2 series, > > which supports next generation onion services, I would love to make > > OnionShare use these by default.

Re: [tor-dev] IPv6 and v3 onion services

On 15 Dec (04:31:45), teor wrote: > On 15 Dec 2017, at 04:04, David Goulet <dgou...@torproject.org> wrote: > > >> On 15 Dec (03:47:25), teor wrote: > >> > >>>> On 15 Dec 2017, at 03:29, David Goulet <dgou...@torproject.org> wrote: > >

Re: [tor-dev] IPv6 and v3 onion services

On 15 Dec (03:47:25), teor wrote: > > > On 15 Dec 2017, at 03:29, David Goulet <dgou...@torproject.org> wrote: > > > > The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in > > IPv6. This seems a more critical point to build into the net

Re: [tor-dev] IPv6 and v3 onion services

On 12 Dec (09:54:43), teor wrote: > Hi David (and others interested in IPv6), > > We want to add better IPv6 support to Tor relays, clients, and v3 onion > services. > > But if we do IPv6 v3 onion services first, the hop before intro and rend > points > will know that the circuit is a v3 onion

Re: [tor-dev] Connection, Channel and Scheduler - An Intense Trek

On 16 Nov (09:06:03), Nick Mathewson wrote: > On Thu, Nov 16, 2017 at 8:56 AM, David Goulet <dgou...@torproject.org> wrote: > > > > On 15 Nov (13:49:54), Nick Mathewson wrote: > > [...] > > > > > On the other hand, this doesn't mean that the FIFO st

Re: [tor-dev] Connection, Channel and Scheduler - An Intense Trek

On 15 Nov (13:49:54), Nick Mathewson wrote: > On Mon, Oct 30, 2017 at 3:57 PM, David Goulet <dgou...@ev0ke.net> wrote: [snip] > > > > Through this epic journey, we've discovered some issues as well as design > > problems. Now the question is what should and can do abou

Re: [tor-dev] Connection, Channel and Scheduler - An Intense Trek

On 12 Nov (14:56:57), Roger Dingledine wrote: > On Mon, Oct 30, 2017 at 03:57:04PM -0400, David Goulet wrote: > > 2. DESTROY cells handling > >· > > Within a circuitmux object, there is a "destroy cell queue" on which a > > DESTROY > > cell i

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

On 10 Nov (04:06:55), teor wrote: > > > On 10 Nov 2017, at 03:17, Yawning Angel <yawn...@schwanenlied.me> wrote: > > > > On Thu, 9 Nov 2017 10:13:45 -0500 > > David Goulet <dgou...@ev0ke.net> wrote: > >>>> Ok fun! I'll add this. Goo

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

On 09 Nov (09:27:15), Yawning Angel wrote: > On Tue, 7 Nov 2017 12:20:15 -0500 > David Goulet <dgou...@ev0ke.net> wrote: > > > This might need a couple more details; as-is ADD_ONION can take > > > "NEW:BEST" (which should now return a v3 service?) or >

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

On 07 Nov (12:47:43), David Goulet wrote: > On 07 Nov (09:40:36), Damian Johnson wrote: > > > What do you propose exactly? > > > > Hi David. What I mean is that having an optional positional field... > > > > MyEvent Field1 Field2 [Field3] Key1=Value1 > &

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

On 07 Nov (09:40:36), Damian Johnson wrote: > > What do you propose exactly? > > Hi David. What I mean is that having an optional positional field... > > MyEvent Field1 Field2 [Field3] Key1=Value1 > > ... means we cannot ever add more positional fields in the future. For > example... > >

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

eing. To have a revocation system like that, we need some sort of mechanism that remembers revoked keys at maybe the directory level of as a complete new entity that keeps a registry of those. We do not have a way to do that nor a proposal for it :S... David > > @ > > On Mon, No

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

On 06 Nov (22:35:32), meejah wrote: > David Goulet <dgou...@ev0ke.net> writes: > > Hi David, > > Overall looks good! A few comments inline: > > > "onions/{current,detached}" > >No change. This command can support v3 hidden service with

Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port

ink I should just not extend that field and use a new "key=value" for it? Thanks! David > > > On Mon, Nov 6, 2017 at 6:59 AM, David Goulet <dgou...@ev0ke.net> wrote: > > Hi everyone, > > > > Attached is the proposal draft for the hidden service v3 contro p

[tor-dev] Proposal 284: Hidden Service v3 Control Port

with that is only extending what exists. Any kind of feedbacks is welcome! :) Cheers! David -- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= Filename: 284-hsv3-control-port.txt Title: Hidden Service v3 Control Port Author: David Goulet Created: 02-November-2017 Status: Open 1. Summary This document

Re: [tor-dev] Connection, Channel and Scheduler - An Intense Trek

On 01 Nov (07:31:50), Ian Goldberg wrote: > On Wed, Nov 01, 2017 at 02:28:03PM +1100, teor wrote: > > > > > On 31 Oct 2017, at 06:57, David Goulet <dgou...@ev0ke.net> wrote: > > > > > > * I believe now that we should seriously discuss the relevance of &

Re: [tor-dev] Connection, Channel and Scheduler - An Intense Trek

On 01 Nov (14:28:03), teor wrote: > > > On 31 Oct 2017, at 06:57, David Goulet <dgou...@ev0ke.net> wrote: > > > > * I believe now that we should seriously discuss the relevance of channels. > > Originally, the idea was good that is providing an abstraction layer

Re: [tor-dev] prop224: Deprecating SHA1 circuit digests

On 23 Jul (12:08:25), teor wrote: > > > On 22 Jul 2017, at 00:07, David Goulet <dgou...@ev0ke.net> wrote: > > > > On 22 Jul (00:02:33), teor wrote: > >> Hi all, > >> > >> At the moment, Tor uses SHA1 for the running digests of circuit c

Re: [tor-dev] prop224: Time Period Overlaps and Blinded Keys

On 21 Jun (11:40:39), teor wrote: > Hi, Hello teor! Sorry for the delay! > > The time period overlap section 2.2.4 in prop224 is under-specified: > https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n821 > > 1. During the overlap period, does the service use the new

Re: [tor-dev] maatuska s bwscanner down since 2017-04-14 - significant drop in relay traffic

On 20 Apr (15:46:46), relayopera...@openmailboxbeta.com wrote: > > On Thu, Apr 20, 2017 at 10:54:21AM -, relayopera...@openmailboxbeta.com > > wrote: > >> Hi Tom! > >> since maatuska's bwscanner is down [1] I see a significant drop of traffic > >> on many of my relays, and I believe this is

Re: [tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

On 11 Apr (13:45:41), George Kadianakis wrote: > George Kadianakis <desnac...@riseup.net> writes: > > > Ian Goldberg <i...@cs.uwaterloo.ca> writes: > > > >> On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote: > >>> Another thing about t

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

On 05 Apr (09:50:38), David Goulet wrote: > On 27 Mar (04:58:34), Ian Goldberg wrote: > > On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote: > > > > To add an aside from a discussion with Teor: the entire "version" field > > > > could be

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

On 27 Mar (04:58:34), Ian Goldberg wrote: > On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote: > > > To add an aside from a discussion with Teor: the entire "version" field > > > could be reduced to a single - probably "zero" - bit, in a manner perhaps > > > similar to the distinctions

Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

On 28 Mar (11:19:45), Tom Ritter wrote: > It seems reasonable but my first question is the UI. Do you have a > proposal? The password field UI works, in my opinion, because it > shows up when the password field is focused on. Assuming one uses the > mouse to click on it (and doesn't tab to it

Re: [tor-dev] Netflow padding

On 19 Feb (01:01:01), grarpamp wrote: > Are these the current / recommended paper refs for > eyeballing things on this to date? > > torspec/proposals/251-netflow-padding.txt This is being considered for 0.3.1 so hopefully we get it in. https://trac.torproject.org/projects/tor/ticket/16861 >

Re: [tor-dev] Prop224 oppurtunity: keygen, crypt, sign, encoding tools

On 15 Feb (19:02:22), grarpamp wrote: > Tor could ship with a tool to offline generate all the > various keys, encrypt and sign with them, for debug, test, and > use with other apps that tie to tor. > And a tool to translate strings between different encodings in use. > Or at least provide howto

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

On 26 Jan (15:05:26), George Kadianakis wrote: > Hey list, > > with service-side prop224 implementation moving forward, we need to pin down > the directory structure of prop224 onion services. This will be very similar > to > the current directory structure, but with some mods to facilitate

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

On 31 Jan (14:26:52), Ivan Markin wrote: > On Tue, Jan 31, 2017 at 02:54:50PM +0200, George Kadianakis wrote: > > I merged my prop224 onion encoding patch to torspec just now, after > > fixing the bug that Ivan mentioned above. > > Thanks! > > btw it's not clear how H() output should be

  1   2   3   >