On 4/23/20 1:48 PM, Matt Traudt wrote:
> 5.4 Other Changes/Investigations/Ideas
>
> - How can FlashFlow data be used in a way that doesn't lead to poor
> load balancing given the following items that lead to non-uniform
> client behavior:
> - Guards that high-traffic HSs choose (for 3 mont
> Before we go further, can you walk me through the reasons (if you had thought
> of it of course) why you didn't use something like libunbound?
>
> There are side effects of adding DNSSEC client support (with our own
> implementation) that we, people maintaining tor, have to become DNSSEC expert
> To me, extra round-trips over the Tor network in the critical path of
> "user clicks and waits for the website to load" are really bad, and
> need a really good argument for being there. Given that DNS is only one
> piece of the connection -- after all, the exit relay can still route you
> somewh
Alexander Færøy:
> I wonder if it would make more sense to have an onion-aware
> DNSSEC-enabled resolver *outside* of the Tor binary and have a way for
> Tor to query an external tool for DNS lookups.
I'm also in favor of this approach,
and you can do this today with no code changes to tor at all
> I can not really say anything about how this design compares to other
> approaches, since I don't know how I can setup meaningful test
> scenarios to compare them.
Do we really need test setups to discuss protocol designs
and compare protocols with a common threat model if specs for the
protoc
On Fri, May 15, 2020 at 05:39:23PM +0200, Christian Hofer wrote:
> Final remarks. When I started, I didn't expect it to get this big, and
> frankly, if I had known before, I might not have even started. However,
> I learned a lot about DNS, DNSSEC, SOCKS, and Tor. So even if you
> decide not to mer
Alexander Færøy:
> Hey,
>
> On 2020/05/15 16:36, Jeremy Rand wrote:
>> The Prop279 spec text is ambiguous about whether the target is required
>> to be a .onion domain, but the implementations (TorNS and StemNS) do not
>> have that restriction. TorNS and StemNS allow a Prop279 plugin to
>> advert
Hey,
On 2020/05/15 16:36, Jeremy Rand wrote:
> The Prop279 spec text is ambiguous about whether the target is required
> to be a .onion domain, but the implementations (TorNS and StemNS) do not
> have that restriction. TorNS and StemNS allow a Prop279 plugin to
> advertise acceptance of any domai
Alexander Færøy:
> Hey Jeremy,
>
> On 2020/05/15 15:53, Jeremy Rand wrote:
>> FYI I already wrote a Prop279 provider that looks up the names via DNS
>> (it's aptly named "dns-prop279"); it does pretty much exactly what you
>> describe. It doesn't handle DNSSEC validation itself (it assumes that
>
Hey Jeremy,
On 2020/05/15 15:53, Jeremy Rand wrote:
> FYI I already wrote a Prop279 provider that looks up the names via DNS
> (it's aptly named "dns-prop279"); it does pretty much exactly what you
> describe. It doesn't handle DNSSEC validation itself (it assumes that
> you've specified a DNS se
On Fri, 2020-05-15 at 15:29 +, Alexander Færøy wrote:
> Hello Christian,
>
Hi Alex!
> On 2020/04/26 19:37, Christian Hofer wrote:
> > I have a proposal regarding DNS name resolution.
> >
> > Ticket: https://trac.torproject.org/projects/tor/ticket/34004
> > Proposal:
> > https://trac.torpro
Alexander Færøy:
> I wonder if it would make more sense to have an onion-aware
> DNSSEC-enabled resolver *outside* of the Tor binary and have a way for
> Tor to query an external tool for DNS lookups. Such tool should be
> allowed to use Tor itself for transport of the actual queries. One of
> the
On Thu, 2020-05-14 at 15:56 -0400, David Goulet wrote:
> On 26 Apr (19:37:56), Christian Hofer wrote:
> > Hi there,
>
> Greetings Christian!
>
Hi David!
> > I have a proposal regarding DNS name resolution.
> >
> > Ticket: https://trac.torproject.org/projects/tor/ticket/34004
> > Proposal:
> >
Hello Christian,
On 2020/04/26 19:37, Christian Hofer wrote:
> 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-name-resolution.txt
> Im
Hi David,
> On 15 May 2020, at 20:53, David Goulet wrote:
>
> On 15 May (13:58:06), teor wrote:
>>
>> 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
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
16 matches
Mail list logo
