Re: [tor-dev] [network-team] [doodle poll] Meeting to discuss guard proposal draft status
Nick Mathewson nickm@torproject.org writes:
[ text/plain ] Hi!
We should do proposal discussion meetings again. In particular, we should talk about this draft I've been working on for a revised version of the twstrike team's revised version of Isis's revised version of the guard selection and rotation algorithm.
I've been tracking my work on ticket #19468: https://trac.torproject.org/projects/tor/ticket/19468
There's some commentary happening on gitlab: https://gitlab.com/asn/torspec/merge_requests/2
I expect I'll do another round of revision by Wednesday.
I'm trying to schedule a time for us to get together to review this, so that we can divide it up into tickets to implement it, ideally based on the twstrike code that we have for the prior revision.
Hello!
With Nick we settled on Thursday at 14:00 UTC as the time for this meeting! The plan is to finish the meeting in strictly less than 90 minutes.
#tor-dev is the place :)
See you there!
George Kadianakis transcribed 1.6K bytes:
Hello!
With Nick we settled on Thursday at 14:00 UTC as the time for this meeting! The plan is to finish the meeting in strictly less than 90 minutes.
Hey George, Hey Everyone,
If we do it Thursday at 16:00 UTC (or later), I could attend, but not before, since I will be on a flight. If it works out better for everyone else to have it at 14:00 instead, then that's also fine with me and please just let me know afterwards what I can do to help.
Best regards,
On Tue, Jul 5, 2016 at 11:44 PM, isis agora lovecruft isis@torproject.org wrote:
George Kadianakis transcribed 1.6K bytes:
Hello!
With Nick we settled on Thursday at 14:00 UTC as the time for this meeting! The plan is to finish the meeting in strictly less than 90 minutes.
Hey George, Hey Everyone,
If we do it Thursday at 16:00 UTC (or later), I could attend, but not before, since I will be on a flight. If it works out better for everyone else to have it at 14:00 instead, then that's also fine with me and please just let me know afterwards what I can do to help.
Does anybody object to 1600 UTC on Thursday?
Nick Mathewson nickm@alum.mit.edu writes:
[ text/plain ] On Tue, Jul 5, 2016 at 11:44 PM, isis agora lovecruft isis@torproject.org wrote:
George Kadianakis transcribed 1.6K bytes:
Hello!
With Nick we settled on Thursday at 14:00 UTC as the time for this meeting! The plan is to finish the meeting in strictly less than 90 minutes.
Hey George, Hey Everyone,
If we do it Thursday at 16:00 UTC (or later), I could attend, but not before, since I will be on a flight. If it works out better for everyone else to have it at 14:00 instead, then that's also fine with me and please just let me know afterwards what I can do to help.
Does anybody object to 1600 UTC on Thursday?
Hm. I can't do 16:00 UTC this Thursday :(
On Wed, Jul 6, 2016 at 10:38 AM, George Kadianakis desnacked@riseup.net wrote:
Nick Mathewson nickm@alum.mit.edu writes:
[ text/plain ] On Tue, Jul 5, 2016 at 11:44 PM, isis agora lovecruft isis@torproject.org wrote:
George Kadianakis transcribed 1.6K bytes:
Hello!
With Nick we settled on Thursday at 14:00 UTC as the time for this meeting! The plan is to finish the meeting in strictly less than 90 minutes.
Hey George, Hey Everyone,
If we do it Thursday at 16:00 UTC (or later), I could attend, but not before, since I will be on a flight. If it works out better for everyone else to have it at 14:00 instead, then that's also fine with me and please just let me know afterwards what I can do to help.
Does anybody object to 1600 UTC on Thursday?
Hm. I can't do 16:00 UTC this Thursday :(
Okay. Then let's plan this: We meet at 1400 UTC. Later, I'll be around at 1600 UTC (or a bit later) to chat with Isis about where we're at, and with anybody else who wants to chat more too.
peace,
Nick Mathewson transcribed 1.1K bytes:
Various questions and responses to the meeting logs [0]:
1. I'm not sure I understand the difference between USABLE_FILTERED_GUARD and CONFIRMED_GUARDS.
2. It seems like USED_GUARDS and CONFIRMED_GUARDS are being used interchangeably. I realise that Nick at some point in IRC mentions the former was renamed to the latter, but it isn't consistent and with so many variables I'm finding myself a bit confused.
3. From:
14:14:41 <nickm> (There is also a secret novelty in how it handles bridges and entrynodes)
I don't actually see EntryNodes mentioned in the proposal?
4. How were all the parameters in §A.1 [1] chosen? Did we simulate the algorithm yet and fuzz the parameters under different network conditions like we did before?
5. For
14:22:11 <nickm> #action try to think of ways that the "don't add to USED_GUARDS till we use it" rule can be manipulated by an attacker
I assume the function governing membership in the set of FILTERED_GUARDS pushes old/stale/less-usable/less-good guards out of the set when new ones are found? That is, the size of FILTERED_GUARDS can't just grow indefinitely, right?
6. For "treating primariness as a continuum", do you mean that we should assign some float values to a bunch of guards we're trying all in parallel, then pick the guard that succeeded that had the highest value? I worry a bit that this would complicate the code and potentially result in many attempted connected to substantially less-suitable nodes.
[0]: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-07-07-13.59.log.html [1]: https://trac.torproject.org/projects/tor/attachment/ticket/19468/prop259-red...
On Mon, Jul 11, 2016 at 12:41 PM, isis agora lovecruft isis@torproject.org wrote:
Nick Mathewson transcribed 1.1K bytes:
Various questions and responses to the meeting logs [0]:
- I'm not sure I understand the difference between USABLE_FILTERED_GUARD and CONFIRMED_GUARDS.
USABLE_FILTERED_GUARDS is a subset of FILTERED_GUARDS where "is running" is "yes" or "maybe".
- It seems like USED_GUARDS and CONFIRMED_GUARDS are being used interchangeably. I realise that Nick at some point in IRC mentions the former was renamed to the latter, but it isn't consistent and with so many variables I'm finding myself a bit confused.
Right. CONFIRMED_GUARDS is the new name for USED_GUARDS. I should replace every instance of the old.
- From:
14:14:41 <nickm> (There is also a secret novelty in how it handles bridges and entrynodes)
I don't actually see EntryNodes mentioned in the proposal?
Appendix A.2 ?
- How were all the parameters in §A.1 [1] chosen? Did we simulate the algorithm yet and fuzz the parameters under different network conditions like we did before?
All were totally pulled out of thin air, or out of the previous iteration of the proposal.
- For
14:22:11 <nickm> #action try to think of ways that the "don't add to USED_GUARDS till we use it" rule can be manipulated by an attacker
I assume the function governing membership in the set of FILTERED_GUARDS pushes old/stale/less-usable/less-good guards out of the set when new ones are found? That is, the size of FILTERED_GUARDS can't just grow indefinitely, right?
FILTERED_GUARDS can only grow up to the size of SAMPLED_GUARDS; but the size of SAMPLED_GUARDS is limited by MAX_SAMPLE_THRESHOLD.
- For "treating primariness as a continuum", do you mean that we should assign some float values to a bunch of guards we're trying all in parallel, then pick the guard that succeeded that had the highest value? I worry a bit that this would complicate the code and potentially result in many attempted connected to substantially less-suitable nodes.
It would mean that instead of treating the first N_PRIMARY_GUARDS members of CONFIRMED_GUARDS as 100% primary, and the remaining members as 0% primary, we would somehow treat the i'th gmember of CONFIRMED_GUARDS as f(i)% primary for some f.
Right now "primariness" is used for several things: we'd need to look at which of these should look at a boolean, and which could instead look at a continuous variable. I do not yet know whether this is a good idea.
-- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
cheers,
Based on comments, I have uploaded a new version at https://trac.torproject.org/projects/tor/ticket/19468
I really hope this is the last draft before we call it a proposal.
On 12 Jul 2016, at 23:55, Nick Mathewson nickm@torproject.org wrote:
Based on comments, I have uploaded a new version at https://trac.torproject.org/projects/tor/ticket/19468
I really hope this is the last draft before we call it a proposal.
I wrote a belated review of the latest version on: https://trac.torproject.org/projects/tor/ticket/19468#comment:12
I would have been happy to do it on a gitlab, but I couldn't find one.
To summarise:
What about directory guards? (I think it's ok to ignore them, with caveats) What about ClientPreferIPv6ORPort? (this needs to be part of the filter or prioritisation or both) Some suggestions about how to fix some complex issues.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B OTR 8F39BCAC 9C9DDF9A DF5FAE48 1D7D99D4 3B406880 ricochet:ekmygaiu4rzgsk6n
On 12 Jul 2016, at 23:55, Nick Mathewson nickm@torproject.org wrote:
Based on comments, I have uploaded a new version at https://trac.torproject.org/projects/tor/ticket/19468
I really hope this is the last draft before we call it a proposal.
I wrote a belated review of the latest version on: https://trac.torproject.org/projects/tor/ticket/19468#comment:12
I would have been happy to do it on a gitlab, but I couldn't find one.
To summarise:
What about directory guards? (I think it's ok to ignore them, with caveats) What about ClientPreferIPv6ORPort? (this needs to be part of the filter or prioritisation or both) Some suggestions about how to fix some complex issues.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B OTR 8F39BCAC 9C9DDF9A DF5FAE48 1D7D99D4 3B406880 ricochet:ekmygaiu4rzgsk6n
-
George Kadianakis -
isis agora lovecruft -
Nick Mathewson -
Nick Mathewson -
Tim Wilson-Brown - teor