Re: [tor-dev] How to introduce new RELAY_COMMAND_* types and new cell fields?

[Tom van der Woerdt]

Op 10/09/15 om 04:10 schreef Mike Perry:

I'm writing a handful of proposals that need to introduce either new
cell sub-payloads or new command types. Specifically, I want to add:

1. Sub-fields to CELL_PADDING to allow clients to tell relays about the
amount of link padding they want for Proposal 251. Mobile clients will
probably want less or no padding, and need some way to say so. Adding
this information to CELL_PADDING itself seemed to be an easy choice.

2. Sub-fields to RELAY_COMMAND_TRUNCATED and CELL_DESTROY to include
HMAC data for Proposal 253.

3. Additional RELAY_COMMAND_* types for clients to request out-of-band
HMAC request cells for Proposal 253.

4. Additional RELAY_COMMAND_* opcodes for clients to request padding
from relays (for an upcoming padding negotiation proposal).


I *think* that fields for items #1 and #2 can be simply added to the
existing cell definitions, since we specify that cells should already be
0-filled, and I can rely on 0 fields to mean that the additional fields
are absent. It should be OK if relays simply ignore/omit these fields
until those proposals are implemented. Is this OK?

However, for items #3 and #4, if I introduce a new RELAY_COMMAND type
and send it to a relay that doesn't support it, then that relay will
emit a warning log message from connection_edge_process_relay_cell() in
relay.c. How should I detect support? Based on advertised relay version
in the consensus? What about non-standard relay implementations that
don't use Tor's versioning?


I don't think you can use the consensus for this: for HS connections you 
wont have any relay info.


How about introducing very basic version info into 
created2/extended/rendezvous cells? You'd have to be really careful to 
not leak too much version info, of course.


Tom




smime.p7s
Description: S/MIME-cryptografische ondertekening
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to introduce new RELAY_COMMAND_* types and newcell fields?

[tordev123]

>> 3. Additional RELAY_COMMAND_* types for clients to request out-of-band
>> HMAC request cells for Proposal 253.

Do you need to request that data? How about always sending it from middle 
nodes? (Less leakage about the client.)

>> 4. Additional RELAY_COMMAND_* opcodes for clients to request padding
>> from relays (for an upcoming padding negotiation proposal).
>>
>> However, for items #3 and #4, if I introduce a new RELAY_COMMAND type
>> and send it to a relay that doesn't support it, then that relay will
>> emit a warning log message from connection_edge_process_relay_cell() in
>> relay.c. How should I detect support? Based on advertised relay version
>> in the consensus? What about non-standard relay implementations that
>> don't use Tor's versioning?
>
> I don't think you can use the consensus for this: for HS connections you
> wont have any relay info.

Wouldn't matter for 4, right?

> How about introducing very basic version info into 
> created2/extended/rendezvous cells? You'd have to be really careful to 
> not leak too much version info, of course.

It seems much better to avoid that, if there is a workaround.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

[Yawning Angel]

On Thu, 10 Sep 2015 07:01:58 +
isis  wrote:
>  3. Should we change how the BridgeAuthority tests Bridge ORPort
> reachability? If so, how?
> 
>  4. If I'm going to refactor all of this, are there other (future)
> things I should take into account?
> 
> For example, if self-testing is disabled for Bridges, and, due to
> #7349, [2] the BridgeAuthority isn't testing reachability either,
> then how will the BridgeAuthority know if (any of) the Bridge's PTs
> are reachable? (One solution might be to, in that case, have the
> BridgeAuthority lie and tell BridgeDB that such Bridges were
> reachable, letting BridgeDB do the PT reachability testing.)

All of this seems to me like we need to sit down somewhere (in
meatspace or online), map out how the current system of:

 * Clients
 * Bridges
 * Bridge Guards
 * The Bridge Authority

fits together, and figure out how it can be redesigned in a way that is
more inline with how things work now/need to work now (PTs were not a
thing when this started being one of the bigger stumbling blocks).

Regards,

-- 
Yawning Angel


pgpNTCxTZUKfj.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Partitioning Attacks on Prop250 (Re: Draft Proposal: Random Number Generation During Tor Voting)

[David Goulet]

On 09 Sep (23:21:03), George Kadianakis wrote:
> Nick Mathewson  writes:
> 
> > On Tue, Sep 8, 2015 at 7:10 AM, David Goulet  wrote:
> >> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:
> >>>
> >>> > On 7 Sep 2015, at 23:36, David Goulet  wrote:
> >>> > ...
> >>> > Please review it, mostly format of the state (before the SR document)
> >>> > has changed. As well as a new "conflict" line is added to the vote.
> >>> > …
> >>>
> >>>
> >>> > If an authority sees two distinct commitments from an other authority in
> >>> > the same period, the authority is broken or evil: you include both, 
> >>> > thereby
> >>> > proving there is a conflict:
> >>> >
> >>> > "shared-rand-conflict" SP identity SP commit1 SP commit2 NL
> >>> >
> >>> > where "identity" is the hex-encoded commitment's authority fingerprint.
> >>> > "commit1" is the previous commit that the authority had in its state and
> >>> > "commit2" is the new received commit of the same period. Both commit 
> >>> > values
> >>> > are constructed as specified in section [COMMITENCODING].
> >>>
> >>>
> >>> What if there are more than two conflicting commitments?
> >>> Should they all be included?
> >>> Is there a denial of service opportunity here, where an authority just 
> >>> keeps generating commitments to fill up the state files?
> >>
> >> Hrm... that is a good point!
> >>
> >> We could put in a maximum number of conflicts let's say 5 and add a
> >> timestamp to it (meh...). Or when voting, we only add the latest per
> >> "identity". I think the important part is just that "oh at this period,
> >> we have a proof of conclict, wtf".
> >
> > It's sufficient to log two conflicting commitments per authority for
> > the same period in order to prove that a conflict exists.  There's no
> > reason to keep more.
> >
> >> But tbh, I'm less and less confident about this because for example an
> >> authority voting then rebooting immediately and then voting again will
> >> trigger a conflict even though this is totally acceptable I think
> >> (assuming the initial commit value was not saved in the state on disk).
> >
> > I say, "Save before publishing, and make sure you don't do two
> > commitments for one period."  Assuming this kind of accident happens
> > very rarely, I don't think we need a way to allow it to succeed
> > anyway.
> 
> Hello,

Hi!

Thanks for this George, very thorough anlysis. Took me a while to
formulate a response and lots of text came out but please read it
carefully and point me wrong if needed :).

> 
> I have mixed feelings about this shared-rand-conflict mechanism.  It indeed
> seems to solve a problem, but not the nasty one. And it's not trivial to
> implement.
> 
> [ Let's say we have 9 dirauths. One of them is evil. Majority needs 5 
> dirauths in this case.
>   For a consensus to be considered valid, it needs 5 dirauth signatures. ]
> 
> I think the attacker we are worrying about here is the one that during the
> Commitment Phase attempts to partition the dirauths in two sets (4 auths in
> group A, and 4 auths in group B). To achieve that the attacker sends a vote 
> with
> commitment c_1 to group A, and a different vote with commitment c_2 to group 
> B.
> 
> Then in the next commitment round the attacker does the same, and now the two
> groups both think they have majority (group A has 4 auths and the attacker,
> group B the same). So they both update their internal state accordingly.

Hrm, I think you don't need to change the commitment value to make the
partition attack. The attacker simply sends c_1 and c_2 once and since
it's majority (group + attacker) both group will keep the value they
got. Now, the attacker just needs to send both reveals to the right
group and job done, two consensuses with two SR values, no?

If yes, that means that the conflict line doesn't mitigate that at all.

Maybe the majority here needs to NOT include yourself when you decide
which value to use or not? For example, if we have 9 dirauths, you want
5 dirauths to agree with you *NOT* counting yourself.

9 - yourself == 8
majority --> floor(8 / 2) + 1 == 5

As a quick example on why it seems to mitigate the attack:

Group A + attacker == 5 dirauths with value c_1
Group B + attacker == 5 dirauths with value c_2

If you are in group A, you'll see 4 dirauths voting c_2 (group B) and 4
dirauths voting for c_1 (group A + attacker - yourself). No majority,
reject value from attacker.

> 
> The attacker can keep on doing the same, and when the Commitment Phase is over
> he will have persuaded both groups that they have the right commitment, if he
> keeps on lying during the Reveal Phase as well (by sending the right reveal
> value to the two groups) he could eventually succeed in making two different
> consensuses with two different shared random values.
> 
> Or an alternative ending scenario would be that the attacker chooses to not
> publish any consensus signatures during the last round of the 

[tor-dev] CollecTor data of the current month older than 72 hours

[nusenu]

Hi,

data in the /recent folder goes back 72 hours,
/archive is updated "every few days" [1].

The latest file in the archive folder [2] is currently from 2015-09-07:

votes-2015-08.tar.xz07-Sep-2015 04:11   159M

but does not contain any data from September 2015.

is there currently any data for the time period between
2015-09-01 - 2015-09-07 9:00
on Collector or should I wait a few days?


thanks!


[1] https://collector.torproject.org/
[2]  https://collector.torproject.org/archive/relay-descriptors/votes/



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

[isis]

Hey all,

I have a working implementation of proposal #188, [0] which specifies a
mechanism by which tor's (rather accidental) loose-source routing feature is
utilised by Bridges in order to transparently inject a Bridge Guard into all
client circuits.  (See #7144. [1])

Currently, I am updating the text in proposal #188 to match my implementation,
and I am trying to decide what to do about the two types of Bridge ORPort
reachability testing.  Here's the text I've written so far to explain the
issues:

(In the following, "Alice" is an OP, "Bob" is a Bridge, "Guillaume" is
Bob's chosen Entry Guard, and "Charlie" is a random Middle node.)

> 4.4. Bridge Reachability Testing
> 
>Currently, a Bridge's reachability is tested both by the Bridge
>itself (called "self-testing") and by the BridgeAuthority.
> 
> 4.4.1. Bridge Reachability Self-Testing
> 
>Before a Bridge uploads its descriptors to the BridgeAuthority, it
>creates a special type of testing circuit which ends at itself:
> 
>Bob -> Guillaume -> Charlie -> Bob
> 
>Thus, going to all this trouble to later use loose-source routing in
>order to relay Alice's traffic through Guillaume (rather than
>connecting directly to Charlie, as Alice intended) is diminished by
>the fact that Charlie can still passively enumerate Bridges by
>waiting to be asked to connect to a node which is not
>contained within the consensus.
> 
>We could get around this option by disabling self-testing for bridges
>entirely, by automatically setting "AssumeReachable 1" for all Bridge
>relays… although I am not sure if this is wise.
> 
> 4.4.2. Bridge Reachability Testing by the BridgeAuthority
> 
>After receiving Bob's descriptors, the BridgeAuthority attempts to
>connect to Bob's ORPort by making a direct TLS connection to the
>Bridge's advertised ORPort.
> 
>Should we change this behaviour?  One the one hand, at least this
>does not enable any random OR in the entire network to enumerate
>Bridges.  On the other hand, any adversary who can observe packets
>from the BridgeAuthority is capable of enumeration.  

So, my current questions are:

 1. Bridges only do reachability self-testing in order to warn their operators
that the Bridge (or firewall or whatever) might be misconfigured, correct?
Is there any other reason (or future reason) why self-testing is
important/useful?

 2. How should the self-testing be changed?

2.a. First, if there aren't any other reasons for self-testing: Is Bridge
 reachability self-testing actually helpful to Bridge operators in
 practice?  Don't most Bridge operators just try to connect, as a
 client, to their own Bridge to see if it's working correctly?  (This
 is what I usually do, at least…)

 If it's not useful to most Bridge operators, can we just disable
 self-testing for all Bridges?  (And, should we disable it only for
 Bridges who are using Bridge Guards, or all of Bridges regardless?)

2.b. If it is useful to people, then the best way I can think of so far to
 keep it, but refactor it to be safer, would be to create a circuit
 like:

 Bridge → Guard → Middle → OtherMiddle → Guard → Bridge

 Clearly, that circuit is just a little bit insane… but we can't do:

 Bridge → Guard → Middle → Guard → Bridge

 because the Middle would refuse to extend back to the previous node
 (all ORs follow this rule).  Similarly, it would be stupid to do:

 Bridge → Guard → Middle → OtherMiddle → Bridge

 because, obviously, that merely shifts the problem and accomplishes
 nothing.  But is there something smarter I could do?

 3. Should we change how the BridgeAuthority tests Bridge ORPort reachability?
If so, how?

 4. If I'm going to refactor all of this, are there other (future) things I
should take into account?

For example, if self-testing is disabled for Bridges, and, due to #7349,
[2] the BridgeAuthority isn't testing reachability either, then how will
the BridgeAuthority know if (any of) the Bridge's PTs are reachable?
(One solution might be to, in that case, have the BridgeAuthority lie and
tell BridgeDB that such Bridges were reachable, letting BridgeDB do the PT
reachability testing.)

Please help me brainstorm a way out of this mess!

[0]: 
https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt
[1]: https://bugs.torproject.org/7144
[2]: https://bugs.torproject.org/7349

Best Regards,
-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt



signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org

Re: [tor-dev] How to introduce new RELAY_COMMAND_* types and newcell fields?

[Tom van der Woerdt]

On 10 Sep 2015, at 12:37, tordev...@safe-mail.net wrote:

>>> 3. Additional RELAY_COMMAND_* types for clients to request out-of-band
>>> HMAC request cells for Proposal 253.
> 
> Do you need to request that data? How about always sending it from middle 
> nodes? (Less leakage about the client.)
> 
>>> 4. Additional RELAY_COMMAND_* opcodes for clients to request padding
>>> from relays (for an upcoming padding negotiation proposal).
>>> 
>>> However, for items #3 and #4, if I introduce a new RELAY_COMMAND type
>>> and send it to a relay that doesn't support it, then that relay will
>>> emit a warning log message from connection_edge_process_relay_cell() in
>>> relay.c. How should I detect support? Based on advertised relay version
>>> in the consensus? What about non-standard relay implementations that
>>> don't use Tor's versioning?
>> 
>> I don't think you can use the consensus for this: for HS connections you
>> wont have any relay info.
> 
> Wouldn't matter for 4, right?

Indeed, I was replying to the more generic case of 'how to detect support for 
feature X'

Tom


> 
>> How about introducing very basic version info into 
>> created2/extended/rendezvous cells? You'd have to be really careful to 
>> not leak too much version info, of course.
> 
> It seems much better to avoid that, if there is a workaround.


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

[Brandon Wiley]

On Thu, Sep 10, 2015 at 12:55 AM, Yawning Angel 
wrote:

>
> FWIW, I don't particularly think that there must be One True PT
> language[0], I just recommend Go over the other alternatives due to it
> being both memory safe and easy to build on mobile. If someone writes a
> new PT in Python, I don't consider it a deal breaker, though it won't
> be as useful due to the difficulty of mobile support.
>
> [0]: MUST be able to be built deterministically. SHOULD be memory
> safe.  Past that, people can do what they want.  If they ignore the
> SHOULD clause, the code needs to undergo more thorough auditing before
> it will be deployed into production.
>
>
I'm not advocating that the various PT implementations be abandoned, just
that we have a common implementation across products when possible. If I
recall correctly, there was a time when TBB, Tails, and Orbot were all
shipping different implementations. I think the current state of PT
implementation deployment is the following:

TBB: Go, Python
Tails: Go
Orbot: Go, C++ (on x86)

The benefit of having the Go implementation ship with all products is that
PT authors can target one implementation and achieve deployment across all
of the products.

As far as reproducibility of builds goes, if a reproducible Python build is
a challenge, an alternative is to port FTE to Go and retire flashproxy.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

[Yawning Angel]

On Thu, 10 Sep 2015 10:20:59 -0400
Brandon Wiley  wrote:
> I'm not advocating that the various PT implementations be abandoned,
> just that we have a common implementation across products when
> possible. If I recall correctly, there was a time when TBB, Tails,
> and Orbot were all shipping different implementations. I think the
> current state of PT implementation deployment is the following:
> 
> TBB: Go, Python
> Tails: Go
> Orbot: Go, C++ (on x86)

That's correct. It's worth noting that the Python component of TBB is
almost entirely FTE that hovers around ~200 users.  Out of those, I am
unsure how many use FTE because it is the only thing that works in
their environment.

> The benefit of having the Go implementation ship with all products is
> that PT authors can target one implementation and achieve deployment
> across all of the products.

Sure.  Go would be a fine choice for people, but I'd like it to be
explicit that I'm open to more options, even if it means reducing the
deployment base if that's what it takes for people to write something
(I'd rather see more circumvention methods, than fewer).

> As far as reproducibility of builds goes, if a reproducible Python
> build is a challenge, an alternative is to port FTE to Go and retire
> flashproxy.

Or port both to Go (flashproxy would be easy)/deprecate both. 

Regards,

-- 
Yawning Angel


pgpeJvU5SJO1N.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Partitioning Attacks on Prop250 (Re: Draft Proposal: Random Number Generation During Tor Voting)

[Nick Mathewson]

On Wed, Sep 9, 2015 at 4:21 PM, George Kadianakis  wrote:
> Nick Mathewson  writes:
>
>> On Tue, Sep 8, 2015 at 7:10 AM, David Goulet  wrote:
>>> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote:

 > On 7 Sep 2015, at 23:36, David Goulet  wrote:
 > ...
 > Please review it, mostly format of the state (before the SR document)
 > has changed. As well as a new "conflict" line is added to the vote.
 > …


 > If an authority sees two distinct commitments from an other authority in
 > the same period, the authority is broken or evil: you include both, 
 > thereby
 > proving there is a conflict:
 >
 > "shared-rand-conflict" SP identity SP commit1 SP commit2 NL
 >
 > where "identity" is the hex-encoded commitment's authority fingerprint.
 > "commit1" is the previous commit that the authority had in its state and
 > "commit2" is the new received commit of the same period. Both commit 
 > values
 > are constructed as specified in section [COMMITENCODING].


 What if there are more than two conflicting commitments?
 Should they all be included?
 Is there a denial of service opportunity here, where an authority just 
 keeps generating commitments to fill up the state files?
>>>
>>> Hrm... that is a good point!
>>>
>>> We could put in a maximum number of conflicts let's say 5 and add a
>>> timestamp to it (meh...). Or when voting, we only add the latest per
>>> "identity". I think the important part is just that "oh at this period,
>>> we have a proof of conclict, wtf".
>>
>> It's sufficient to log two conflicting commitments per authority for
>> the same period in order to prove that a conflict exists.  There's no
>> reason to keep more.
>>
>>> But tbh, I'm less and less confident about this because for example an
>>> authority voting then rebooting immediately and then voting again will
>>> trigger a conflict even though this is totally acceptable I think
>>> (assuming the initial commit value was not saved in the state on disk).
>>
>> I say, "Save before publishing, and make sure you don't do two
>> commitments for one period."  Assuming this kind of accident happens
>> very rarely, I don't think we need a way to allow it to succeed
>> anyway.
>
> Hello,
>
> I have mixed feelings about this shared-rand-conflict mechanism.  It indeed
> seems to solve a problem, but not the nasty one. And it's not trivial to
> implement.

It seemed comparatively simple to implement to me.  After all, relays
must already store one commitment per authority.  With
conflict-checking proposal, they must store up to two commitments per
authority.  I don't see what the hard part is.

> [ Let's say we have 9 dirauths. One of them is evil. Majority needs 5 
> dirauths in this case.
>   For a consensus to be considered valid, it needs 5 dirauth signatures. ]
>
> I think the attacker we are worrying about here is the one that during the
> Commitment Phase attempts to partition the dirauths in two sets (4 auths in
> group A, and 4 auths in group B). To achieve that the attacker sends a vote 
> with
> commitment c_1 to group A, and a different vote with commitment c_2 to group 
> B.

So, this should get detected during the consensus phase, since there
will be a conflicting vote-digest for the authority in question. The
attack will be detectable at that point, even without the
conflict-detection in my proposal.

> Then in the next commitment round the attacker does the same, and now the two
> groups both think they have majority (group A has 4 auths and the attacker,
> group B the same). So they both update their internal state accordingly.

In my proposal, the next commitment round, the attack will be
detected, when the voters declare which commitments they believe in.
(Even without conflict detection!)

> The attacker can keep on doing the same, and when the Commitment Phase is over
> he will have persuaded both groups that they have the right commitment, if he
> keeps on lying during the Reveal Phase as well (by sending the right reveal
> value to the two groups) he could eventually succeed in making two different
> consensuses with two different shared random values.
>
> Or an alternative ending scenario would be that the attacker chooses to not
> publish any consensus signatures during the last round of the protocol, and 
> then
> neither of the groups achieves enough signatures to make a valid consensus. 
> And
> consensus at 12:00UTC fails, and no shared random for today.
>
> ---
>
> So OK these are two reasonable attacks that shared-rand-conflict can
> address. The attacks are very noisy and detectable but they work. Why am I
> saying that shared-rand-conflcit does not mitigate everything?
>
> It's because IIUC the attacker could also do the same attacks by following the
> protocol normally and then doing the partitioning attack during the last 
> rounds
> 

[tor-dev] [PATCH] Update prop#188 to match implementation from #7144.

[Isis Lovecruft]

 * ADD a new section detailing loose-source routed circuits, including:
 - How the circuit should appear to the OP, the bridge, and the
   bridge guard,
 - How the hop(s) in the path is/are chosen,
 - How the first hop is handled and how circuit extension is
   handled, in a generalised sense (i.e. not specific to a bridge
   using bridge guards),
 - Which cell types are used and how they are chosen,
 - When the original create cell is answered (in relation to when
   cells are sent to the other additional hops),
 - What should be done when relay cells are received when the
   additional hops in the loose-source routed circuit are not
   fully constructed,
 - How the circuit crypto and cell digests for incoming/outgoing
   relay cells works (again, in a generalised sense, i.e. not
   specific to bridges using bridge guards),
 - How and whether a given relay cell is treated as "recognized",
 - Under what circumstances (based on whether a stream is attached
   and which relay command was sent) should cause a node which
   uses loose-source routed circuits to drop a relay cell or mark
   a circuit for close, and,
 - When and what statistics should be gathered for loose-source
   routed circuits.

 * UPDATE and clarify the example loose-source routed circuit
   construction (the original one from the proposal which was specific
   to a client using a bridge that uses bridge guards).

 * CHANGE the "Make it harder to tell clients from bridges" section
   which described the tradeoffs between using CREATE versus
   CREATE_FAST cells for the first additional hop (i.e. the bridge
   guard).  Those concerns is no longer entirely relevant, since, in
   the meantime, we've introduced the NTor handshake and it's
   extremely likely that both the client and the bridge will use
   CREATE2 for all their hops.

 * ADD a new section on enumerating bridges via the behaviours
   inherent to bridge reachability testing.

 * REMOVE open question (from the very end of the proposal) regarding
   whether the standard guard selection algorithms are adequate.  They
   are.  (Even if they are convoluted and overly-complicated.)
---
 proposals/188-bridge-guards.txt | 458 
 1 file changed, 369 insertions(+), 89 deletions(-)

diff --git a/proposals/188-bridge-guards.txt b/proposals/188-bridge-guards.txt
index 5a5a005..c4d354f 100644
--- a/proposals/188-bridge-guards.txt
+++ b/proposals/188-bridge-guards.txt
@@ -1,7 +1,8 @@
 Filename: 188-bridge-guards.txt
 Title: Bridge Guards and other anti-enumeration defenses
-Author: Nick Mathewson
+Author: Nick Mathewson, Isis Lovecruft
 Created: 14 Oct 2011
+Modified: 10 Sep 2015
 Status: Open
 
 1. Overview
@@ -76,111 +77,317 @@ Status: Open
remove, and remove a layer of encryption on incoming cells on that
circuit corresponding to the encryption that the guard will add.
 
-3.1. An example
+3.1. Loose-Source Routed Circuit Construction
 
-   This example doesn't add anything to the design above, but has some
-   interesting inline notes.
+   Alice, an OP, is using a bridge, Bob, and she has chosen the
+   following path through the network:
 
-  - Alice has connected to her bridge Bob, and built a circuit
-through Bob, with the negotiated forward and reverse keys KB_f
-and KB_r.
+   Alice -> Bob -> Charlie -> Deidra
 
-  - Alice then wants to extend the circuit to node Charlie.  She
-makes a hybrid-encrypted onionskin, encrypted to Charlie's
-public key, containing her chosen g^x value.  She puts this in
-an extend cell: "Extend (Charlie's address) (Charlie's OR
-Port) (Onionskin) (Charlie's ID)".  She encrypts this with
-KB_f and sends it as a RELAY_EARLY cell to Bob.
+   However, Bob has decided to take advantage of the loose-source
+   routing circuit characteristic (for example, in order to use a bridge
+   guard), and Bob has chosen N additional loose-source routed hop(s),
+   through which he will transparently relays cells.
 
-  - Bob receives the RELAY_EARLY cell, and decrypts it with KB_f.
-He then sees that it's an extend cell for him.
+   NOTE: For the purposes of bridge guards, N is always 1.  However, for
+   completion's sake, the following details of the circuit construction
+   are generalized to include N > 1.  Additionally, the following steps
+   should hold for a hop at any position in Alice's circuit that has
+   decided to take advantage of the loose-source routing feature, not
+   only for bridge ORs.
 
-So far, this is exactly the same as the current procedure that
-Alice and Bob would follow.  Now we diverge:
+   From Alice's perspective, her circuit path matches the one diagrammed
+   above.  However, the overall path of the circuit is:
 
-  - Instead of connecting to Charlie directly, Bob makes sure that
-he is connected to his 

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

[Tom Ritter]

On 10 September 2015 at 02:01, isis  wrote:
> 2.a. First, if there aren't any other reasons for self-testing: Is Bridge
>  reachability self-testing actually helpful to Bridge operators in
>  practice?  Don't most Bridge operators just try to connect, as a
>  client, to their own Bridge to see if it's working correctly?  (This
>  is what I usually do, at least…)

Yes it is helpful; no I don't/can't always do that.  IPv6 is one
issue*. Finding the correct incantation is another**.  =)

-tom

* Yes I know I can get free IPv6 tunnels from tunnelbroker, no I don't
want to; it is complicated.
** See my email from earlier this summer about piecing everything
together to test a bridge.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-reports] Sebastian's August 2015

[Sebastian Hahn]

> On 11 Sep 2015, at 07:04, ilv  wrote:
>> Next up is more of the same, especially focusing on website tickets
>> and preparing the community team's dev meeting contributions.
> 
> Maybe we could have a session at the dev meeting to talk about the
> website (content, structure, translations, etc.). What do you think?
> 
> (cc'ing @tor-dev in case more people are interested)

Yes, Lunar has suggested this as well.

Cheers
Sebastian


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-reports] Sebastian's August 2015

[ilv]

On 06/09/15 13:01, Sebastian Hahn wrote:
> Hi there,
> 

Hi Sebastian,

> Next up is more of the same, especially focusing on website tickets
> and preparing the community team's dev meeting contributions.


Maybe we could have a session at the dev meeting to talk about the
website (content, structure, translations, etc.). What do you think?

(cc'ing @tor-dev in case more people are interested)

Saludos.
--ilv



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

[isis]

Yawning Angel transcribed 2.7K bytes:
> On Thu, 10 Sep 2015 07:01:58 +
> isis  wrote:
> >  3. Should we change how the BridgeAuthority tests Bridge ORPort
> > reachability? If so, how?
> > 
> >  4. If I'm going to refactor all of this, are there other (future)
> > things I should take into account?
> > 
> > For example, if self-testing is disabled for Bridges, and, due to
> > #7349, [2] the BridgeAuthority isn't testing reachability either,
> > then how will the BridgeAuthority know if (any of) the Bridge's PTs
> > are reachable? (One solution might be to, in that case, have the
> > BridgeAuthority lie and tell BridgeDB that such Bridges were
> > reachable, letting BridgeDB do the PT reachability testing.)
> 
> All of this seems to me like we need to sit down somewhere (in
> meatspace or online), map out how the current system of:
> 
>  * Clients
>  * Bridges
>  * Bridge Guards
>  * The Bridge Authority
> 
> fits together, and figure out how it can be redesigned in a way that is
> more inline with how things work now/need to work now (PTs were not a
> thing when this started being one of the bigger stumbling blocks).
> 
> Regards,
> 
> -- 
> Yawning Angel

Sounds like something we could work on at the dev meeting? :)

-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev