On 10 Oct (09:57:20), Nick Mathewson wrote:
[...]
> I like Tor-over-QUIC and think it's a neat idea, but there's a lot of
> investigation to be done. I wonder what some logical next steps would
> be here?
Many moons ago, Mike spent considerable time evaluating this. You can see a
summary here:
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
>
>
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:
> > >
> > > > ```
> > &
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
> > ```
> >
> > # Mot
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
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.
>
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 w
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
cli
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 the
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 pa
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 answe
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
> ra
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
> > >
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?
>
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overlo
On 03 Oct (18:16:05), nusenu wrote:
> Hi,
>
> I wrote down a spec for a simple web of trust
> for relay operator IDs:
>
> https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-operator-ids/proposals/ideas/xxx-simple-relay-operator-wot.md#a-simple-web-of-trust-for-tor-relay-oper
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
> >
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
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 considering
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%, n
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 127.0.0.1
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 forever
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:
> >>
>
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
>
>
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/-/
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
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 reque
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 ou
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
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: S
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 th
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
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
>
> Here
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:
> https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-dns-nam
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
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
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 Servi
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 p
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 plac
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?
>
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
> http
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 go
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
> https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c75550456716074911e685#diff-9fd3400f062c4541d79881e199f
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 c
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...
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 i
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
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 impl
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
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
>
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
> &g
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
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.
>
&
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
> >
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
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 that
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 s
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
>
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 al
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):
>
> https://github.com/torproject/torspec/pull/81/commits/3a26880e80617210b47
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
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
exporting
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
>
I did this 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
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 ach
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:
> >>
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
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...
> >
> > https://trac.tor
On 22 Mar (17:13:40), Mike Perry wrote:
> David Goulet:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> > > Mike Perry writes:
> > >
> > > > Arguments in favor of switching to two entry guards:
> > > >
> > > >
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
> > https://trac.torproject.org/projects/tor/ticket/122
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
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 it
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 c
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 wrote:
> > >
> > > Now that Tor Browser 7.5 is released and includes the tor 0.3.2 series,
> > > which supports next ge
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. Here is the issue [1].
>
On 15 Dec (04:31:45), teor wrote:
> On 15 Dec 2017, at 04:04, David Goulet wrote:
>
> >> On 15 Dec (03:47:25), teor wrote:
> >>
> >>>> On 15 Dec 2017, at 03:29, David Goulet wrote:
> >>>
> >>> The place I'm thinking of is t
On 15 Dec (03:47:25), teor wrote:
>
> > On 15 Dec 2017, at 03:29, David Goulet 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 network before we
> > ca
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
On 16 Nov (09:06:03), Nick Mathewson wrote:
> On Thu, Nov 16, 2017 at 8:56 AM, David Goulet wrote:
> >
> > On 15 Nov (13:49:54), Nick Mathewson wrote:
>
> [...]
> >
> > > On the other hand, this doesn't mean that the FIFO structure we have today
> &
On 15 Nov (13:49:54), Nick Mathewson wrote:
> On Mon, Oct 30, 2017 at 3:57 PM, David Goulet 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 about it?
> >
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 is pu
On 10 Nov (04:06:55), teor wrote:
>
> > On 10 Nov 2017, at 03:17, Yawning Angel wrote:
> >
> > On Thu, 9 Nov 2017 10:13:45 -0500
> > David Goulet wrote:
> >>>> Ok fun! I'll add this. Good catch! And control-spec.txt should be
> >>>&
On 09 Nov (09:27:15), Yawning Angel wrote:
> On Tue, 7 Nov 2017 12:20:15 -0500
> David Goulet wrote:
> > > This might need a couple more details; as-is ADD_ONION can take
> > > "NEW:BEST" (which should now return a v3 service?) or
> > > "NEW:ED
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
> &
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...
>
> MyEven
sk it ends up being.
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 06 Nov (22:35:32), meejah wrote:
> David Goulet writes:
>
> Hi David,
>
> Overall looks good! A few comments inline:
>
> > "onions/{current,detached}"
> >No change. This command can support v3 hidden service without changes
> >
mat. So, you think 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 wrote:
> > Hi everyone,
> >
> > Attached is the proposal draft for the hidden service v3 contro port
> &
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
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 wrote:
> > >
> > > * I believe now that we should seriously discuss the relevance of
> > > channels.
On 01 Nov (14:28:03), teor wrote:
>
> > On 31 Oct 2017, at 06:57, David Goulet wrote:
> >
> > * I believe now that we should seriously discuss the relevance of channels.
> > Originally, the idea was good that is providing an abstraction layer for
> > the
>
Hello everyone!
DISCLAIMER: The following is enormous and tries to describe in some level of
details the situation in tor with connection<->channel<->scheduler. This comes
after we've merged the KIST scheduler, we've realized many things we'ren't what
they were suppose to be or meant for. In the e
On 23 Jul (12:08:25), teor wrote:
>
> > On 22 Jul 2017, at 00:07, David Goulet wrote:
> >
> > On 22 Jul (00:02:33), teor wrote:
> >> Hi all,
> >>
> >> At the moment, Tor uses SHA1 for the running digests of circuit cell
> >> payloads.
&g
On 22 Jul (00:02:33), teor wrote:
> Hi all,
>
> At the moment, Tor uses SHA1 for the running digests of circuit cell
> payloads.
>
> Some of the prop224 code seems to use SHA256 for the digests for
> client to service rendezvous circuits. But that's not in the spec yet
> (see #22995 at [0]).
Tha
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
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 r
On 11 Apr (13:45:41), George Kadianakis wrote:
> George Kadianakis writes:
>
> > Ian Goldberg writes:
> >
> >> On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote:
> >>> Another thing about this I just thought of. This AONT construction seems
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 reduce
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 b
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 from
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
> tor
1 - 100 of 260 matches
Mail list logo
