[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]

Post by 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!

Hello!

Last chance (for this round) to get your nominations/votes in! This week I
will be creating subthreads (of this thread) for each proposal meeting, which
will have doodles/polls for dates and times.

Unless someone requests otherwise, I'm not going to group proposals into
batches for meetings: hopefully this way the meetings will be shorter and
people only have to pay attention to the things they are interested in.

Best regards,

[isis agora lovecruft]

Hello,

Let's schedule a proposal discussion for prop#239 "Consensus Hash Chaining"
[0] sometime next week (between 7 - 9 Feb). If you're CCed, it's because
you put your name down on the pad as being interested in this discussion.
If anyone has requests or concerns, or if I forgot to take your timezone
into account, please let me know.

https://doodle.com/poll/iahmzu95hpvxciex

[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-chaining.txt

[isis agora lovecruft]

This is happening in #tor-meeting on Thursday, 8 February, 21:00-22:00 UTC.
In various local times:

* Thursday, 8 February, 13:00-14:00 PST
* Thursday, 8 February, 16:00-17:00 EST
* Thursday, 8 February, 22:00-23:00 CET
* Friday, 9 February, 08:00-09:00 AEST

Post by isis agora lovecruft
Hello,
Let's schedule a proposal discussion for prop#239 "Consensus Hash Chaining"
[0] sometime next week (between 7 - 9 Feb). If you're CCed, it's because
you put your name down on the pad as being interested in this discussion.
If anyone has requests or concerns, or if I forgot to take your timezone
into account, please let me know.
https://doodle.com/poll/iahmzu95hpvxciex
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-chaining.txt

Best regards,

[isis agora lovecruft]

Hi!

The notes from this meeting are online. [0] Thanks to everyone who attended!

We've decided to have the prop#267 [1] meeting next, then (potentially, depending on
the takeaway from the prop#267 meeting) revise prop#239 [2] according to these
notes. Finally, we'll (potentially) have a third meeting to compare and
contrast the two proposals, and choose one to go with.

[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-08-20.59.html
[1]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-transparency.txt
[2]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-chaining.txt

Best regards,

[Linus Nordberg]

Post by isis agora lovecruft
Hi!
The notes from this meeting are online. [0] Thanks to everyone who attended!
We've decided to have the prop#267 [1] meeting next, then (potentially, depending on
the takeaway from the prop#267 meeting) revise prop#239 [2] according to these
notes. Finally, we'll (potentially) have a third meeting to compare and
contrast the two proposals, and choose one to go with.
[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-08-20.59.html[1]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-transparency.txt[2]: https://gitweb.torproject.org/torspec.git/tree/proposals/239-consensus-hash-chaining.txt

Thanks for arranging this meeting and apologies for not showing up as
planned.

For convenience, here are the highlighted items from the meeting. They
didn't make it to the meeting minutes page. (Seems like #info, #action
and #idea are what meetbot cares about.)

--8<---------------cut here---------------start------------->8---
<nickm> #item proposal should clarify how many older consensuses to hold
<teor> #item why not just keep the hash(es) of each consensus
<nickm> #item maybe use sha3-256 instead.
<nickm> #item maybe store only the hash and the signatures. Have the chaining
<tjr> #item Instead of keeping full documents, can we keep a chain of diffs?
<teor> #item expand "some categories of attacks" to explain what the attacks
<tjr> #item Provide an export of a suspicious consensus that would prove
<tjr> #item It would be good to look at prop267 again in relation to this
--8<---------------cut here---------------end--------------->8---

[isis agora lovecruft]

Hello,

Let's schedule a proposal discussion for prop#285 "Directory documents
should be standardized as UTF-8" [0] sometime between 12 - 13 Feb. If
you're CCed, it's because you put your name down on the pad as being
interested in this discussion. If anyone has requests or concerns, or if I
forgot to take your timezone into account, please let me know.

https://doodle.com/poll/cnc6scybbfpky5f8

[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt

Best regards,

[isis agora lovecruft]

Reminder to please vote for a time for this if you'd still like to attend!

Post by isis agora lovecruft
Hello,
Let's schedule a proposal discussion for prop#285 "Directory documents
should be standardized as UTF-8" [0] sometime between 12 - 13 Feb. If
you're CCed, it's because you put your name down on the pad as being
interested in this discussion. If anyone has requests or concerns, or if I
forgot to take your timezone into account, please let me know.
https://doodle.com/poll/cnc6scybbfpky5f8
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt

Best regards,

[isis agora lovecruft]

This one is in #tor-meeting, next Monday, 12 February from 21:00-22:00 UTC.
In local times:

* Monday, 12 February 13:00-14:00 PST
* Monday, 12 February 16:00-17:00 EST
* Monday, 12 February 22:00-23:00 CET
* Tuesday, 13 February 08:00-09:00 AEST

Post by isis agora lovecruft
Reminder to please vote for a time for this if you'd still like to attend!

Post by isis agora lovecruft
Hello,
Let's schedule a proposal discussion for prop#285 "Directory documents
should be standardized as UTF-8" [0] sometime between 12 - 13 Feb. If
you're CCed, it's because you put your name down on the pad as being
interested in this discussion. If anyone has requests or concerns, or if I
forgot to take your timezone into account, please let me know.
https://doodle.com/poll/cnc6scybbfpky5f8
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt

[isis agora lovecruft]

Hi!

The notes from this meeting are online. [0] Thanks to everyone who
attended! Extra thanks to teor for conducting the meeting since I was
stupidly 8 minutes late due to impatiently watching a kettle boil
after eating very spicy cioppino and then *extremely* needing a glass
of iced tea immediately.

We found some issues w.r.t. the specifics of the proposal, but overall
we've agreed that it should be accepted in (roughly, after some minor
revision) in its current state. As such, it is looking for someone
interested in implementing it! (THIS COULD BE YOU)

A couple outcomes of this:

1. What passes for "canonicalised" "utf-8" in C will be different to
what passes for "canonicalised" "utf-8" in Rust. In C, the
following will not be allowed (whereas they are allowed in Rust):
- NUL (0x00)
- Byte Order Mark (0xFEFF)

2. Directory document keywords MUST be printable ASCII.

3. This change may break some descriptor/consensus/document parsers.
If you are the maintainer of a parser, you may want to start
thinking about this now.

[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-12-21.04.html

Best regards,

[teor]

Post by isis agora lovecruft
1. What passes for "canonicalised" "utf-8" in C will be different to
what passes for "canonicalised" "utf-8" in Rust. In C, the
- NUL (0x00)
- Byte Order Mark (0xFEFF)

I want to clarify this point:

The Byte Order Mark is Unicode Scalar 0xFEFF, encoded in UTF-8 as the
bytes 0xEF 0xBB 0xBF.

Tor's C and Rust implementations of UTF-8 must be identical.

When we write the C implementation, we must reject NUL for
compatibility with C string functions.

When we write the Rust implementation, we must reject NUL for
compatibility with the C implementation. (Rust already implements
UTF-8 strings that accept NUL, so this will require custom code).

When we write the C and Rust implementations, we must reject BOM
because it's unnecessary. Rejecting BOM is recommended by the
relevant standard. (Rust already implements UTF-8 strings that accept
BOM, so this will require custom code).

T

[Iain Learmonth]

Hi,

Post by isis agora lovecruft
1. What passes for "canonicalised" "utf-8" in C will be different to
what passes for "canonicalised" "utf-8" in Rust. In C, the
- NUL (0x00)
- Byte Order Mark (0xFEFF)

Much of the metrics software is written in Java. Java strings allow for
NUL to appear, but assume that there is no BOM. If a BOM appears, then
this would be interpreted as data and, I assume, parsing would probably
fail. Should the whole document be rejected if it contains a NUL or BOM,
or should these values be stripped and then carry on parsing as if it
never happened?

Post by isis agora lovecruft
2. Directory document keywords MUST be printable ASCII.

This can be validated. Should a single document keyword containing
printable non-ASCII be enough to reject the document, or should a parser
try to recover?

I'd really like to see a section in the proposal about how parsers
should react when they find something unexpected, otherwise all the
parsers may end up doing different things.

Post by isis agora lovecruft
3. This change may break some descriptor/consensus/document parsers.
If you are the maintainer of a parser, you may want to start
thinking about this now.

For the metrics tools there are some guidelines on this we can follow:
https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other
language would be Python (for stem), but Python developers have probably
got a good understanding of unicode/str/bytes by now. (In Python 3: when
using UTF-8, BOM will not be stripped and will be interpreted as data,
and you can have a NUL in a str).

Thanks,
Iain.

[teor]

Post by Iain Learmonth
Hi,

Post by isis agora lovecruft
1. What passes for "canonicalised" "utf-8" in C will be different to
what passes for "canonicalised" "utf-8" in Rust. In C, the
- NUL (0x00)
- Byte Order Mark (0xFEFF)

Much of the metrics software is written in Java. Java strings allow for
NUL to appear, but assume that there is no BOM. If a BOM appears, then
this would be interpreted as data and, I assume, parsing would probably
fail. Should the whole document be rejected if it contains a NUL or BOM,
or should these values be stripped and then carry on parsing as if it
never happened?

Directory authorities and bridge clients already reject descriptors that
contain NUL. (This is an artefact of the C implementation: the descriptor
is seen as truncated, so it won't parse.)

We should specify rejection for BOM as well.

Post by Iain Learmonth

Post by isis agora lovecruft
2. Directory document keywords MUST be printable ASCII.

This can be validated. Should a single document keyword containing
printable non-ASCII be enough to reject the document, or should a parser
try to recover?

If parsers want to be consistent with the Tor implementation, they should
reject.

Post by Iain Learmonth
I'd really like to see a section in the proposal about how parsers
should react when they find something unexpected, otherwise all the
parsers may end up doing different things.

+1

Post by Iain Learmonth

Post by isis agora lovecruft
3. This change may break some descriptor/consensus/document parsers.
If you are the maintainer of a parser, you may want to start
thinking about this now.

https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other
language would be Python (for stem), but Python developers have probably
got a good understanding of unicode/str/bytes by now. (In Python 3: when
using UTF-8, BOM will not be stripped and will be interpreted as data,
and you can have a NUL in a str).

Python for txtorcon
Rust for Tor's experimental protover implementation

And perhaps others:
https://stem.torproject.org/faq.html#are-there-any-other-controller-libraries
https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations

T

[Damian Johnson]

Post by Iain Learmonth
https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other
language would be Python (for stem), but Python developers have probably
got a good understanding of unicode/str/bytes by now. (In Python 3: when
using UTF-8, BOM will not be stripped and will be interpreted as data,
and you can have a NUL in a str).

Hi Iain. Actually, for Stem I'm really looking forward to this too.
Stem has special handling for the contact and platform fields (iirc
the only spot non-ascii content can presently appear). Stem's parsers
and API will be simplified once everything is uniformly utf-8. :P

Possibly a stupid question but any reason not to require the whole
descriptor document to be printable characters?

[teor]

Post by Damian Johnson

Post by Iain Learmonth
https://docs.oracle.com/javase/tutorial/i18n/text/design.html. The other
language would be Python (for stem), but Python developers have probably
got a good understanding of unicode/str/bytes by now. (In Python 3: when
using UTF-8, BOM will not be stripped and will be interpreted as data,
and you can have a NUL in a str).

Hi Iain. Actually, for Stem I'm really looking forward to this too.
Stem has special handling for the contact and platform fields (iirc
the only spot non-ascii content can presently appear). Stem's parsers
and API will be simplified once everything is uniformly utf-8. :P
Possibly a stupid question but any reason not to require the whole
descriptor document to be printable characters?

Requiring printable ASCII throughout the document means that people
can't spell their names and email addresses correctly in contact lines.

Requiring printable unicode introduces a dependency on a particular
unicode version, because we don't know if unallocated blocks will be
printable or not.

I think we could make platform lines printable ASCII without losing
much. Unless there are platforms that have non-ASCII names?

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------

[isis agora lovecruft]

Hello,

Let's schedule a proposal discussion for prop#267 "Tor Consensus
Transparency" [0] sometime between 14 - 16 Feb. If you're CCed, it's
because you put your name down on the pad as being interested in this
discussion. If anyone has requests or concerns, or if I forgot to take your
timezone into account, please let me know.

https://doodle.com/poll/a6ih5a4dqr9bdsie

Note that this meeting will likely run longer than an hour. I'll try to
keep it as short as possible
 but in the past this discussion has been long.

[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-transparency.txt

Best regards,

[Tom Ritter]

On 17 February 2018 at 00:31, isis agora lovecruft
This time works for me.

-tom

[teor]

I'm sorry, I didn't get Isis' original email, I think my spam folder ate it.

Can you please re-send?

Post by Tom Ritter
On 17 February 2018 at 00:31, isis agora lovecruft
This time works for me.

[isis agora lovecruft]

Post by teor
I'm sorry, I didn't get Isis' original email, I think my spam folder ate it.
Can you please re-send?

Of course! I actually didn't get a copy either; not sure what happened there.

Post by teor
Subject: Re: [tor-dev] [prop-meeting] [prop#267] "Tor Consensus Transparency"
Date: Sat, 17 Feb 2018 06:31:03 +0000

Post by isis agora lovecruft
Hello,
Let's schedule a proposal discussion for prop#267 "Tor Consensus
Transparency" [0] sometime between 14 - 16 Feb. If you're CCed, it's
because you put your name down on the pad as being interested in this
discussion. If anyone has requests or concerns, or if I forgot to take your
timezone into account, please let me know.
https://doodle.com/poll/a6ih5a4dqr9bdsie
Note that this meeting will likely run longer than an hour. I'll try to
keep it as short as possible
 but in the past this discussion has been long.
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-transparency.txt

Oh no!
I'm so sorry; I totally messed up and forgot to choose the best time
for people and announce it! I knew this was going to happen at some
point; way more meetings to keep track of than I or probably any of us
are used to.
I was thinking about this a bit before: we generally seem to have two
disjoint sets of groups of people where no one "has to draw the short
1. americas + europe
2. australia + americas
I'm not sure how to do this, but perhaps there a way to vote such that
we determine which set we're in, and then we simply have
pre-determined meeting times each week for both groups, and we arrange
the meetings for the interested groups at those set times? Would that
work with most people's schedules? Or would it be too much of a
burden to guarantee another weekly meeting? We could also
duplicate/rehash meeting notes between meetings, if both sets are
equivalently interested in a topic.
(Also, there is a potential third set of "australia + europe" which
we've missed due to cognitive biases of having too many people in the
americas.)
Please let me know your thoughts! I'm not totally sold on this idea,
but I want to find a way to make discussions easier and better for
everyone. Especially remembering that they are happening. *blush*
Please feel free to request alternate times! Especially for people in
Europe, these times aren't quite fair. (However, I'm also not seeing
as much participation for european residents according to the pad and
doodles.)
Best regards,
--
♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt

----- End forwarded message -----

[isis agora lovecruft]

Hello,

I know I said I wouldn't group meetings in bulk
 but there's a few
meetings which have the following in common:

* Everyone who said they wished to attend is: me, teor, and nickm.¹
* The discussion should be fairly fast.
* We're all (I suspect) already in agreement.
* Every topic has to do with removing old/deprecated code.

So. Let's schedule, sometime between 19 - 23 Feb, a proposal discussion for:

* prop#245 "Deprecating and removing the TAP circuit extension protocol" [0]
* prop#282 "Remove 'Named' and 'Unnamed' handling from consensus voting" [1]

https://doodle.com/poll/6m9xztyy4ufmeiwy

As always, please let me know if you'd really like to attend but I've not
taken your timezone into account.

[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/245-tap-out.txt
[1]: https://gitweb.torproject.org/torspec.git/tree/proposals/282-remove-named-from-consensus.txt

¹ Please note that even if your name is not {isis,teor,nickm} that you are
warmly welcome to attend and participate.

Best regards,

[Nick Mathewson]

On Fri, Feb 9, 2018 at 11:14 PM, isis agora lovecruft

Post by isis agora lovecruft
Hello,
I know I said I wouldn't group meetings in bulk… but there's a few

Hi! I'm afraid I don't know my schedule for that week yet, since my
kid is off school. Please schedule this one without me: I'll try to
make it to the meeting at whatever time everybody else chooses. If I
can't, I'll send notes and read notes.

cheers,

[isis agora lovecruft]

Hello,

Meeting notes are available here. [0] Takeaways include:

* Some minor clarifications to prop#245, but it will be put in "Status:
Accepted" with a ticket to implement and deploy step#1 (§3). We'll need
to actually implement all the other steps too, with parameters to
en-/dis- able them, so that we can properly test them before deployment
(in ~2020).

* prop#282 is accepted, and can be implemented immediately.

* A new proposal summarising our newly created policy for consensus method
deprecation will be written.

Thanks everyone!

[0]: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-02-20-23.11.html

Best regards,