Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[isis]

Virgil Griffith transcribed 10K bytes:
> Yes I did.  Here's the modified proposal.
> 
> Filename: ExtraRelayDescriptorFields.txt
> Title: Adding X-namespace to extra-info descriptor for key:value pairs
> Author: Virgil Griffith
> Created: 2015-09-30
> Status: Open
> 
> 
> 1. Motivation
> We wish to allow developers to build new applications atop relays. Towards
> this end, we wish to add the ability for users to specify arbitrary new
> key-value entries under the "X-" namespace to the extra-info descriptor.
> The canonical applications for this are adding a bitcoin donation address,
> networking of tor2web nodes, and display operator information on a
> Roster[1] page.
> 
> 
> 2. Proposal
> Allow optional key-value lines in the relay's torrc file.
> 
> The following would be added to section 2.1.2 of the dir-spec [2]
> (Extra-info document format):
> 
> 
> "X-" CustomKey SP CustomValue NL
> 
> CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_"
> CustomKey = 1*32 CustomKeyChar
> 
> CustomValueChar = atext / specials
> CustomValue = 1*1024 CustomValueChar
> 
> There can be multiple X-fields, for example...
> 
> X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
> X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
> X-linkedin https://www.linkedin.com/in/virgilgr
> X-keybase http://fncuwbiisyh6ak3i.onion/virgil
> X-favoritequote Be excellent to each other.  Party on dudes!
> X-foo bar
> 
> The same CustomKey appearing more than once is disallowed.
> Possible values for CustomValueChar as specified per RFC 2822
> sections 3.2.1 and 3.2.4 [3].
> 
> The sum size accounting for all such custom fields is truncated to 5
> kilobytes.
> 
> 
> To mitigate the chance of a malformed torrc file, I additionally propose
> that the relay descriptor be scanned and if it does not match the
> specification, that it exit with error telling her torrc file is a likely
> culprit.
> 
> References
> [1] http://tor-roster.org
> [2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700
> [3] https://www.ietf.org/rfc/rfc2822.txt

Hello Virgil,

Some feedback:

A. You still appear to be confusing the terms "torrc" and "extrainfo".

   Or did you mean that there will be both X-Some-Crap torrc options and
   fields in the extrainfo descriptors?

B. Do you mean for all extrainfo descriptors?

   BridgeDB must parse the bridge-extrainfos to obtain transport lines.
   Parsing the bridge-extrainfos is already rather intensive and
   time-consuming, mostly because, people have been shoving more and more
   random cruft into the descriptors.  It sure would suck if BridgeDB had to
   parse up to 5KB more crap per descriptor (which also have to be
   deduplicated, occasionally deduplicating thousands of submitted descriptors
   per hour per relay).  Which brings me to…

C. Why do we need 5KB of unparseable, unspecified, cruft in the descriptors?

   There is some argument to be made for having certain, well-specified
   fields, e.g. a bitcoin address of the relay operator… but a LinkedIn
   address?  Why is this necessary?

D. The extrainfo descriptors are not a message-passing channel for data for
   other applications, nor should they be.

   If you need some application to have the ability to associate your LinkedIn
   address with your relay, then write a program which uses (one of) your
   relay's identity keys to sign the requisite information.

E. "truncated"

   Truncated by whom?  The OP as it parses the torrc and forms its own
   extrainfo descriptor for submission?  Obviously not.  So this must be
   enforced by the DirAuths then?

F. "To mitigate the chance of a malformed torrc file, I additionally propose
   that the relay descriptor be scanned…"

   You're still mixing up torrc files and extrainfo descriptors.

G. "that it exit with error telling her torrc file is a likely culprit"…

   The English objective pronoun, "her," usually requires there to be some
   prior subjective context to explain who the unspecified female object is.
   Additionally, you're using the same occurence of "her" as both the
   objective to "telling" and as the possesive determinant to "torrc".

   Also, poor grammar aside, looking at the ways in which sexism can be
   inherent to the English language, it is frequently the case that females
   are spoken of in the passive voice, and then males in the active voice,
   e.g. when speaking to infants: "Oh, he kicks and squirms so much!" versus
   "Her toes are so cute and tiny."

   Sorry, but this is a bit of a pet peeve of mine, and I'm quite strongly
   against including a female object in the proposal merely so that actions
   can be done *to* her by the programme, rather than by her.

H. "CustomValueChar as specified per RFC 2822"

   Because, clearly, that turned out to be trivially parseable for email and 
HTTP:

   http://stackoverflow.com/a/1732454
   http://stackover

Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[Virgil Griffith]

> A. You still appear to be confusing the terms "torrc" and "extrainfo".

I recognize this error and will fix it.

> B. Do you mean for all extrainfo descriptors?

I support excluding Bridge relays for exactly the reasons you
mentioned.  My sole is to clean up the bitcoin addresses in the
ContactInfo field as well as allow relays to integrate with Roster
better as well as clean up the

> C. Why do we need 5KB of unparseable, unspecified, cruft in the descriptors?

> D. The extrainfo descriptors are not a message-passing channel for data for 
> other applications, nor should they be.

In Paris I asked Roger for a bitcoin field in the ExtraInfo descriptor
because currently Bitcoin addresses are polluting the ContactInfo, and
I'd like to clean that up.

Roger said he couldn't add a bitcoin field because if he made a
bitcoin field then everyone's pet project will ask him for special
ExtraInfo headers.  He proposed instead making an "x-" namespace where
people can scribble in for their pet projects.  This advice seemingly
conflicts with your (D).  In my defense, I was just following orders.


> E. "truncated"

   I say the OP does the truncation.  If someone modifies their Tor
client to create a broken or otherwise unparseable ExtraInfo
descriptor that is their choice, and my understanding is that this
patch does not increase anyone's ability to specify malformed
ExtraInfo descriptors.


> G. "that it exit with error telling her torrc file is a likely culprit"…

I aspire to be more mindful in my gender-inclusive language.


> H. "CustomValueChar as specified per RFC 2822"

Atagar suggested I use RFC 2822 as a template.


That's all I got really.  If someone has an alternative suggestion for
allowing people to specify things like Bitcoin addresses I'm all ears,
but this was the path I was explicitly placed on.  I will correct the
errors (A), (E), (G), (F).  I am all ears on how to fix (H).

-V

On Mon, Nov 9, 2015 at 10:01 PM, isis  wrote:
> Virgil Griffith transcribed 10K bytes:
>> Yes I did.  Here's the modified proposal.
>>
>> Filename: ExtraRelayDescriptorFields.txt
>> Title: Adding X-namespace to extra-info descriptor for key:value pairs
>> Author: Virgil Griffith
>> Created: 2015-09-30
>> Status: Open
>>
>>
>> 1. Motivation
>> We wish to allow developers to build new applications atop relays. Towards
>> this end, we wish to add the ability for users to specify arbitrary new
>> key-value entries under the "X-" namespace to the extra-info descriptor.
>> The canonical applications for this are adding a bitcoin donation address,
>> networking of tor2web nodes, and display operator information on a
>> Roster[1] page.
>>
>>
>> 2. Proposal
>> Allow optional key-value lines in the relay's torrc file.
>>
>> The following would be added to section 2.1.2 of the dir-spec [2]
>> (Extra-info document format):
>>
>> 
>> "X-" CustomKey SP CustomValue NL
>>
>> CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_"
>> CustomKey = 1*32 CustomKeyChar
>>
>> CustomValueChar = atext / specials
>> CustomValue = 1*1024 CustomValueChar
>>
>> There can be multiple X-fields, for example...
>>
>> X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
>> X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
>> X-linkedin https://www.linkedin.com/in/virgilgr
>> X-keybase http://fncuwbiisyh6ak3i.onion/virgil
>> X-favoritequote Be excellent to each other.  Party on dudes!
>> X-foo bar
>>
>> The same CustomKey appearing more than once is disallowed.
>> Possible values for CustomValueChar as specified per RFC 2822
>> sections 3.2.1 and 3.2.4 [3].
>>
>> The sum size accounting for all such custom fields is truncated to 5
>> kilobytes.
>> 
>>
>> To mitigate the chance of a malformed torrc file, I additionally propose
>> that the relay descriptor be scanned and if it does not match the
>> specification, that it exit with error telling her torrc file is a likely
>> culprit.
>>
>> References
>> [1] http://tor-roster.org
>> [2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700
>> [3] https://www.ietf.org/rfc/rfc2822.txt
>
> Hello Virgil,
>
> Some feedback:
>
> A. You still appear to be confusing the terms "torrc" and "extrainfo".
>
>Or did you mean that there will be both X-Some-Crap torrc options and
>fields in the extrainfo descriptors?
>
> B. Do you mean for all extrainfo descriptors?
>
>BridgeDB must parse the bridge-extrainfos to obtain transport lines.
>Parsing the bridge-extrainfos is already rather intensive and
>time-consuming, mostly because, people have been shoving more and more
>random cruft into the descriptors.  It sure would suck if BridgeDB had to
>parse up to 5KB more crap per descriptor (which also have to be
>deduplicated, occasionally deduplicating thousands of submitted descriptors
>per hour per relay).  Which brings me to…
>
> C. Why do we need 5KB of unparseab

Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[Virgil Griffith]

On Mon, Nov 9, 2015 at 10:01 PM, isis  wrote:
>If you need some application to have the ability to associate your LinkedIn
>address with your relay, then write a program which uses (one of) your

For what it's worth, the LinkedIn reference was my attempt at humor to
add levity to otherwise usually dry material.  I concur that it would
be odd if someone put their LinkedIn in their relay's ExtraInfo
descriptor.

> G. "that it exit with error telling her torrc file is a likely culprit"…

For what it's worth, in the first draft of this the pronoun was male,
but I explicitly changed it to female (no personal pronouns are
mentioned anywhere else) because I wanted to be more gender-inclusive.

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

Re: [tor-dev] Special handling of .onion domains in Chrome/Firefox (post-IETF-standarization)

[Alec Muffett]

> On Nov 2, 2015, at 20:39, Paul Syverson  wrote:
> 
> On Mon, Nov 02, 2015 at 09:05:26PM +0200, George Kadianakis wrote:
>> Hello,
>> 
>> as you might know, the IETF recently decided to formally recognize .onion 
>> names
>> as special-use domain names [0].
>> 
>> This means that normal browsers like Chrome and Firefox can now
>> handle onion domains in a special manner since they know that they
>> only correspond to Tor.
>> 
>> How would we like those browsers to treat onions?
>> 
>> For starters, those browsers should refuse to connect to onion
>> domains entirely.  Onions don't work on normal browsers anyway, and
>> also this will reduce the onion leakage through the DNS system [1].
> 
> Well, maybe not "entirely". Cf. below.



Tangential aside: Chrome currently has a bug open in that it does not yet 
support onion certificates:

https://code.google.com/p/chromium/issues/detail?id=483614 


The Onion RFC lays a burden on DNS to NXDOMAIN onion lookups.

It says nothing about having browsers block them.

Perhaps the better thing for Tor adoption is - privacy purism enforced by TBB 
aside - to enable adoption.

Allow (encourage?) non-TBB browsers to be capable to using Onions.

Roger, after all, stood up movingly at the Aaron Swartz memorial and spoke of 
letting people pick the security that _they_ wanted, when connecting to a site.

This would, I feel, accord with that position.

- alec


ps:

> It might be a better idea to point them to tor2web. For one thing
> browser providers will be happier with a display that doesn't directly
> tell people they need a different browser to get to an intended
> address.


Pointing people at tor2web would break SSL, but see this thread, which is a 
side-show to the larger "how can we get personal onion addresses" discussion: 
https://twitter.com/AlecMuffett/status/658440124624183296 



> The display could say something like:
> 
>  Oops, seems like you attempted to visit an onion address, a
>  specialized address that provides additional security for
>  connections to it. The site can be reached via proxy at
>  [tor2web-link-to-relevant-onionsite]. To obtain the intended
>  security for access to such sites, follow   "[link-to-page-w-brief-simple-explanation-n-prominent-link-to-download-TBB]">
>  these few simple steps .
> 
> No doubt some wordsmithing could make this better in various respects
> (amongst them, shorter).



Phishing-potential in such dialogues, here?

-a


> 
>> 
>> 
>> What else could we do here? And is there anyone who can lobby for the right
>> behavior? :)
>> 
>> Of course, we all know that that inevitably those browsers will need
>> to bundle Tor, if they want to visit the actually secure onion
>> Internet. But let's give them a bit more time till they realize this
>> :)
> 
> I think something like the above improves the transition path, helping
> the world along to better security instead of just waiting for the
> world to catch up. (And in any case, perhaps at least a few more
> months work would better prepare us for the resulting attention.)
> 
> aloha,
> Paul
> 


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] Proposal 247 (Hidden Service Vanguards) Overhaul

[Mike Perry]

Aaron Johnson:
> Hi Mike,
> 
> Here are some specific comments on the proposal, most of which I
> didn’t mention at the session yesterday.
> 
> Sec. 2: “When a hidden service picks its guard nodes, it also picks
> two additional sets of middle nodes `second_guard_set` and
> `third_guard_set` of size NUM_SECOND_GUARDS and NUM_THIRD_GUARDS
> respectively for each hidden service.” appears to conflict with “When
> a hidden service needs to establish a circuit to an HSDir,
> introduction point or a rendezvous point, it uses nodes from
> `second_guard_set` as the second hop of the circuit and nodes from
> that second hop's corresponding `third_guard_set` as third hops of the
> circuit”. I think the former statement should be amended to describe
> how the third sets are chosen for each guard in the second set.
> 
> Sec. 3.1: “A Sybil attack is noisy”. “Noisy” in the sense that it
> isn’t perfectly accurate or “noisy” in the sense that it is
> observable?
> 
> Sec. 3.1: “the Sybil success is almost immediately obvious to third
> layer guard, since it will now be returned as a rend point for
> circuits for the hidden service in question”. The third-layer guard
> isn’t the a rendezvous point. So how it is immediately obvious to the
> adversary when their relay is selected as a third-layer guard?

Ok, I have corrected these in 
https://gitweb.torproject.org/user/mikeperry/torspec.git/commit/proposals/247-hs-guard-discovery.txt?h=guard_discovery_dev&id=c5281a6fe2837634cf7767d9f1e89a40cf35737e

I have not yet cleaned up the proposal with the discussion from the dev
meeting. It still is in there in the form of XXX's.
 
> Sec. 3.2.3: I’m not sure that FullCDF() correctly computes the
> rotation CDF (even approximately). It should take into account the
> probability of observing a previous node that has selected the given
> rotation time (longer rotation times are more likely to be observed).
> So the probability that there are exactly t days until rotation of the
> observed node should be proportional to \sum_{i=t}^N Pr[X=i]. After
> normalization to make this a probability, the expression is
> (\sum_{i=t}^N Pr[X=i]) / (\sum_{i=1}^N Pr[X=i]*i).

I understand what you're talking about here, and there is indeed a
mistake in my original CDF calculations. I forgot to account for the
non-uniform time durations of the rotations (ie: weighting their
selection probability proportionally by how long the rotation duration
is).

However, I came up with a different expression than you did for doing
that. I believe that if you pick a time point uniformly at random, then
the time-weighted probability of the rotation duration being r is:

  P(R==r) = ProbMinXX(N,r)*r / \sum_{i=1}^N ProbMinXX(X=i)*i

Here's the commit that updates the proposal with this explaination in
more detail, and uses this new time-weighted P(R==r) to compute the CDF:
https://gitweb.torproject.org/user/mikeperry/torspec.git/commit/proposals/247-hs-guard-discovery.txt?h=guard_discovery_dev&id=59647940489ba804d2273a6bce926a6e78387783

As you can see, this does reduce the CDF rate of increase, as you might
expect from taking this into account. I'm not sure what this change
means with respect to how we pick the constants. I still need to think
about that (but that's probably best withheld until I review all of the
notes from the dev meeting and take them into consideration first).


FWIW: Your P(R==r) expression actually causes the CDF to increase
*faster* (so that the probabilities are higher than before at lower t
values), so that makes me more certain that it's not doing the right
thing.

Here's a quick table of the first few values of P(SECOND_ROTATION <= t):

tOldP(R <= t)   YourP(R <= t)  MyP(R <= t)
1 0.19095 0.24788   0.07701
2 0.3 0.40624   0.15403
3 0.42456 0.52261   0.22829


Here's the python I used to implement your ProbR. You can replace my
ProbR in the script in Appendix A of the proposal to reproduce those
numbers (and also verify I understood your expression correctly):

def ProbR(N, r, ProbFunc=ProbMinXX):
  sum1 = 0.0
  i=r+1
  while i < N:
sum1 += ProbFunc(N, i)
i += 1
  return sum1/ExpFn(N, ProbFunc)

Here's the current head of the full proposal, for convenience:
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/247-hs-guard-discovery.txt?h=guard_discovery_dev

-- 
Mike Perry


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

Re: [tor-dev] Changing Rendezvous Single Onion Service at Runtime

[Nick Mathewson]

On Fri, Nov 6, 2015 at 11:16 AM, teor  wrote:
> Hi all,
>
> Is there any reason an onion service would want to temporarily switch from
> 1-hop to 3-hop paths?
> Is it ok if we force operators to restart the tor instance when onion
> service path lengths change?

Just said on IRC, but saying here too for the record:

IMO it's fine to require a restart for now.  And in fact, there should
be some kind of affirmative opt-in to switch a hidden service
directory from one to the other.

Treating these two kinds of services as interchangeable at
service-side is IMO a recipe for bad times.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev