[tor-dev] Nominate/vote for future proposal discussion meetings!

[isis agora lovecruft]

Hello all,

Is there an existing Tor proposal you'd like to discuss?  Please use
the following pad to nominate and vote for proposals for discussion.

https://pad.riseup.net/p/Pxo2fQiiaSWo

We'll be reviving our proposal discussion meetings soon, likely at the
beginning of January once people have returned from their winter
holidays.

After the nominations/votes are taken, I'll start arranging meeting
times.  If you nominate and/or vote for a proposal, I may reach out to
you at some point for your opinions on discussion items, open
questions/concerns, etc. to include for the meeting preparation.

Thanks!

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.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

[tor-dev] Discussion Meeting for Prop#249 "Large CREATE cells"

[isis agora lovecruft]

Hello all,

What: A proposal discussion meeting for prop#249 "Allow CREATE cells with
  >505 bytes of handshake data". [0]

Who:  This proposal is likely of interest to those hoping to integrate newer,
  non-ECC-based, circuit-layer handshakes into the Tor protocol.

When: Next week, on Monday or Tuesday (or Wednesday, for some timezones).
  If you'd like to attend, please vote on a time here:
  https://doodle.com/poll/v924cbt2at3rzvc9

Where: irc.oftc.net #tor-meeting


[0]: 
https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-cells.txt


Meeting Preparation Materials
=

The following is meant for attendees to refresh before the meeting.  Please
feel free to respond with further summary and/or open questions/concerns.

Proposal Summary

The proposal outlines two new cell types, CREATE2V and CREATED2V, which are
variable-length and (like their CREATE2/CREATED2 counterparts) are sent
encapsulated in EXTEND2 cells.  Due to their variable-length, however, if a
CREATE(D)2V cell's HDATA is larger than the standard allotment of 505 bytes,
these new cells are fragmented across multiple EXTEND2 cells.

Open Questions/Concerns
~~~

1. Since CREATE2V cells are used for handshakes, and several newer,
   post-quantum primitives have asymmetric payloads for the client versus
   server directions, should we require that the CREATE(D)2V padding be used
   to equalise the number of bytes sent in each direction?

2. Should we randomise the bytes in the padding?  (Currently, as proposed,
   we require all-zero padding.)

3. Should we do anything more future-proofed w.r.t. the future possibility
   of using an alternate (non-stateful, e.g. not TCP) transport?
   (Currently, the proposal relies heavily upon the transport-layer to
   provide delivery guarantee and, perhaps more important, ordering.)

4. Shoule we, for hybrid handshakes (handshakes which use multiple separate
   primitives to derive shared secrets, e.g. ECDH+RLWE or ECDH+SIDH, by
   conducting each handshake separately and composing their respective
   resulting shared secrets), design some mechanism where, if a party only
   supports say the ECDH portion of the hybrid handshake and not the RLWE
   part, then they proceed with the portion they understand?  For example, a
   client sends their portion of a ECDH+RLWE handshake to a relay which only
   understands ECDH, so the relay responds with only ECDH and they continue.
   This is mostly a difference in subprotocol versioning for handshakes,
   that is, an ECDH+RLWE handshake, rather than being "handshake type 5" or
   whatever, would be "handshake type 2 AND/OR handshake type 5".

5. As written, the proposal doesn't specify a maximum (or minimum) size of
   handshake data.  However, the max is somewhat limited by the number of
   allowed RELAY_EARLY cells; maximum handshake data is then limited to
   462+(7*492)=3906 bytes.


Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.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

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

On 8 December 2017 at 15:48, teor  wrote:
>
> On 9 Dec 2017, at 03:27, Tom Ritter  wrote:
>
>>> We introduce a new HTTP header called "Onion-Location" with the exact same
>>>   restrictions and semantics as the Location HTTP header.
>>
>> For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2
>
> Because this is a non-standard header, does it need to be spelled:
> "X-Onion-Location"?

Nope =)
https://tools.ietf.org/html/rfc6648

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

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[teor]

On 9 Dec 2017, at 03:27, Tom Ritter  wrote:

>> We introduce a new HTTP header called "Onion-Location" with the exact same
>>   restrictions and semantics as the Location HTTP header.
> 
> For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2

Because this is a non-standard header, does it need to be spelled:
"X-Onion-Location"?

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

Re: [tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

[meejah]

Nick Mathewson  writes:

>We define a new "GETINFO status/hibernation" to inspect the
>current hibernation state.  Possible values are:
>  - "live"
>  - "idle:control"
>  - "idle:no-activity"
>  - "sleep:control"
>  - "sleep:accounting"
>  - "idle-update:control"
>  - "sleep-update:control"
>  - "shutdown:exiting"
>  - "shutdown:accounting"
>  - "shutdown:control"

To me this smells like it should be two different things rather than
overloading "one" state to become two and have all users have to parse
colons. e.g. "status/hibernation" and "status/hibernation-reason" or
similar.

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

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

On 8 December 2017 at 09:06, George Kadianakis  wrote:
> As discussed in this mailing list and in IRC, I'm posting a subsequent
> version of this proposal. Basic improvements:
> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
> - Does not do auto-redirect; it instead suggests the onion based on
>   antonella's mockup: 
> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
>
>
>
> 
> UX improvement proposal: Onion redirects using Onion-Location HTTP header
> 
>
> 1. Motivation:
>
>Lots of high-profile websites have onion addresses these days (e.g. Tor ,
>NYT, blockchain, ProPublica).  All those websites seem confused on what's
>the right way to inform their users about their onion addresses. Here are
>some confusion examples:
>  a) torproject.org does not even advertise their onion address to Tor 
> users (!!!)
>  b) blockchain.info throws an ugly ASCII page to Tor users mentioning 
> their onion
> address and completely wrecking the UX (loses URL params, etc.)
>  c) ProPublica has a "Browse via Tor" section which redirects to the 
> onion site.
>
>Ideally there would be a consistent way for websites to inform their users
>about their onion counterpart. This would provide the following positives:
>  + Tor users would use onions more often. That's important for user
>education and user perception, and also to partially dispell the 
> darkweb myth.
>  + Website operators wouldn't have to come up with ad-hoc ways to 
> advertise
>their onion services, which sometimes results in complete breakage of
>the user experience (particularly with blockchain)
>
>This proposal specifies a simple way forward here that's far from perfect,
>but can still provide benefits and also improve user-education around 
> onions
>so that in the future we could employ more advanced techniques.
>
>Also see Tor ticket #21952 for more discussion on this:
>   https://trac.torproject.org/projects/tor/ticket/21952
>
> 2. Proposal
>
>We introduce a new HTTP header called "Onion-Location" with the exact same
>restrictions and semantics as the Location HTTP header.

For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2

> Websites can use the
>Onion-Location HTTP header to specify their onion counterpart, in the same
>way that they would use the Location header.
>
>The Tor Browser intercepts the Onion-Location header (if any) and informs
>the user of the existense of the onion site, giving them the option to 
> visit
>it. Tor Browser only does so if the header is served over HTTPS.
>
>Browsers that don't support Tor SHOULD ignore the Onion-Location header.
>
> 3. Improvements
>
> 4. Drawbacks
>
> 4.1. No security/performance benefits
>
>While we could come up with onion redirection proposals that provide
>security and performance benefits, this proposal does not actually provide
>any of those.
>
>As a matter of fact, the security remains the same as connecting to normal
>websites (since we trust its HTTP headers), and the performance gets worse
>since we first need to connect to the website, get its headers, and then
>also connect to the onion.

I would specifically call out that the user has provided any
identifying information (cookies) that may be present, as well as
opened themselves to any possible browser-based attack vector served
by the target domain.

>Still _all_ the website approaches mentioned in the "Motivation" section
>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>ways to inform users abou their onions. So this simple proposal will still
>help those websites and also pave the way forward for future auto-redirect
>techniques.
>
> 4.2. Defining new HTTP headers is not the best idea
>
>This proposal defines a new non-standard HTTP header. This is not great
>because it makes Tor into a "special" thing that needs to be supported with
>special headers. However, the fact that it's a new HTTP header that only
>works for Tor is a positive thing since it means that non-Tor browsers will
>just ignore it.
>
>Furthermore, another drawback is that this HTTP header will increase the
>bandwidth needlessly if it's also served to non-Tor clients. Hence websites
>with lots of client traffic are encouraged to use tools that detect Tor
>users and only serve the header to them (e.g. tordnsel).

I would talk about how users could experience false positives and
false negatives if this mechanism is used.



I think it is also worth addressing that this does not stop sysadmins
from (trying to) detect tor users, and send the onion address in the
Location header, thus triggering a non-prompting 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

As discussed in this mailing list and in IRC, I'm posting a subsequent
version of this proposal. Basic improvements:
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
  antonella's mockup: 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png




UX improvement proposal: Onion redirects using Onion-Location HTTP header


1. Motivation:

   Lots of high-profile websites have onion addresses these days (e.g. Tor ,
   NYT, blockchain, ProPublica).  All those websites seem confused on what's
   the right way to inform their users about their onion addresses. Here are
   some confusion examples:
 a) torproject.org does not even advertise their onion address to Tor users 
(!!!)
 b) blockchain.info throws an ugly ASCII page to Tor users mentioning their 
onion
address and completely wrecking the UX (loses URL params, etc.)
 c) ProPublica has a "Browse via Tor" section which redirects to the onion 
site.

   Ideally there would be a consistent way for websites to inform their users
   about their onion counterpart. This would provide the following positives:
 + Tor users would use onions more often. That's important for user
   education and user perception, and also to partially dispell the darkweb 
myth.
 + Website operators wouldn't have to come up with ad-hoc ways to advertise
   their onion services, which sometimes results in complete breakage of
   the user experience (particularly with blockchain)

   This proposal specifies a simple way forward here that's far from perfect,
   but can still provide benefits and also improve user-education around onions
   so that in the future we could employ more advanced techniques.

   Also see Tor ticket #21952 for more discussion on this:
  https://trac.torproject.org/projects/tor/ticket/21952

2. Proposal

   We introduce a new HTTP header called "Onion-Location" with the exact same
   restrictions and semantics as the Location HTTP header. Websites can use the
   Onion-Location HTTP header to specify their onion counterpart, in the same
   way that they would use the Location header.

   The Tor Browser intercepts the Onion-Location header (if any) and informs
   the user of the existense of the onion site, giving them the option to visit
   it. Tor Browser only does so if the header is served over HTTPS.

   Browsers that don't support Tor SHOULD ignore the Onion-Location header.

3. Improvements

4. Drawbacks

4.1. No security/performance benefits

   While we could come up with onion redirection proposals that provide
   security and performance benefits, this proposal does not actually provide
   any of those.

   As a matter of fact, the security remains the same as connecting to normal
   websites (since we trust its HTTP headers), and the performance gets worse
   since we first need to connect to the website, get its headers, and then
   also connect to the onion.

   Still _all_ the website approaches mentioned in the "Motivation" section
   suffer from the above drawbacks, and sysadmins still come up with ad-hoc
   ways to inform users abou their onions. So this simple proposal will still
   help those websites and also pave the way forward for future auto-redirect
   techniques.

4.2. Defining new HTTP headers is not the best idea

   This proposal defines a new non-standard HTTP header. This is not great
   because it makes Tor into a "special" thing that needs to be supported with
   special headers. However, the fact that it's a new HTTP header that only
   works for Tor is a positive thing since it means that non-Tor browsers will
   just ignore it.

   Furthermore, another drawback is that this HTTP header will increase the
   bandwidth needlessly if it's also served to non-Tor clients. Hence websites
   with lots of client traffic are encouraged to use tools that detect Tor
   users and only serve the header to them (e.g. tordnsel).

5. The future

   As previously discussed, this is just a simple proposal to introduce the
   redirection concept to people, and also to help some sysadmins who are
   currently coming up with weird ways to inform people about their
   onions. It's not the best way to do this, but it's definitely one of the
   simplest ways.

   In the future we could implement with more advanced auto-redirect proposals 
like:

   a) Have a "domains to onions" map into HTTPS-everywhere and have it do the
  autoredirects for us (performance benefits, and security benefits under 
many
  threat models).

   b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
  by comment:42 in #21952.

   But both of the designs above require non-trivial engineering/policy work
   and would still confuse people. So I think