[tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
Hi, I made some updates to the ContactInfo Information Sharing Specification draft. Most notably I added a new field 'verifyurl' that should allow the automatic verification of the operatorurl claim. Without it anyone could claim to be part of some operator without the possibility of automated verification. You can get the current version on github: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/blob/master/README.md Please send me your comments before 2020-02-02. I'm planing to tag a v1.0 in February 2020. After that I hope it sees some adoption by major operators so I can use your ContactInfo strings for automated verification and as input for malicious relay detection. thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
nusenu: > Hi, > > I made some updates to the > ContactInfo Information Sharing Specification > draft. > > Most notably I added a new field 'verifyurl' that should allow > the automatic verification of the operatorurl claim. > > Without it anyone could claim to be part of some operator without the > possibility of automated verification. > > You can get the current version on github: > > https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/blob/master/README.md Thanks for writing that draft. I've been looking over earlier discussions of it on tor-dev[1] and tor-relays[2] to get more context for that write-up and I have some questions and suggestions. It seems to me the specification tries to make use of the fact that the ContactInfo field is essentially unstructured text to put things into it, in a slightly structured manner, that could be helpful in a number of areas (bad relay detection, relay metrics, network growth...). I, like others, fear a potential function-creep here essentially wasting the time you put into this important work because nobody is adopting your suggestions (they are opt-in according to your writing). So, my suggestion would be to take a step back and think harder about whether all of those areas would really benefit from the work in your specification or whether we should try to get improvements elsewhere going instead (E.g. I like the idea mentioned by Iain to think about new fields for extrainfo documents[4] for some of this information). As another suggestion that could help thinking about your spec: what about ahf's idea to deprecate ContactInfo and replace it with a more structured format instead? That could go along with the areas above which we *actually* think should be covered by the (original) ContactInfo field? > Please send me your comments before 2020-02-02. > I'm planing to tag a v1.0 in February 2020. > > After that I hope it sees some adoption by major operators so I can use your > ContactInfo strings > for automated verification and as input for malicious relay detection. That's one part I don't understand. You advertise the specification as opt-in and relay operators are free to choose from any of the options[5] but your wording above seems to imply that not following it could make the probability higher that the relay will be marked as bad exit. So, there is supposed to happen a silent enforcement over time of an opt-in spec which is a weird thing to me. (Additionally, what does it mean in your spec that "The email field MUST be provided" given that the whole spec is opt-in?) Again as I said above: we should think about the different areas this spec covers, and if there is anything we want to enforce for $purpose we should think about the best way to do so (having the longer term costs associated with what we pick in mind, too) and then do it. However, we should avoid any ambiguity in that case and not get to a slow enforcement of things we originally propagated as merely opt-in. Georg [1] https://lists.torproject.org/pipermail/tor-dev/2017-October/012507.html ff. [2] https://lists.torproject.org/pipermail/tor-relays/2017-October/013274.html ff. [3] https://trac.torproject.org/projects/tor/ticket/24526#comment:3 [4] https://lists.torproject.org/pipermail/tor-relays/2017-October/013275.html [5] https://lists.torproject.org/pipermail/tor-dev/2017-October/012509.html signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
> It seems to me the specification tries to make use of the fact that the > ContactInfo field is essentially unstructured text to put things into > it, in a slightly structured manner, that could be helpful in a number > of areas (bad relay detection, relay metrics, network growth...). I, > like others, fear a potential function-creep here essentially wasting > the time you put into this important work because nobody is adopting > your suggestions (they are opt-in according to your writing). So, my > suggestion would be to take a step back and think harder about whether > all of those areas would really benefit from the work in your > specification or whether we should try to get improvements elsewhere > going instead (E.g. I like the idea mentioned by Iain to think about new > fields for extrainfo documents[4] for some of this information). It is great if you take this idea an turn it into a tor proposal with new (extra) descriptor fields but in the end it will require operators to adopt it and it probably does not matter much for an operator whether the information is put into a single ContactInfo line or into multiple distinct lines with a slight plus for multiple lines for readability. Parsing is surely cleaner with new descriptor fields. The main point is probably to convince operators that such machine parseable information benefits them and the tor network (at least if you keep the opt-in spirit of the current draft). I mainly went for the ContactInfo field since it does not require any code changes. > As another suggestion that could help thinking about your spec: what > about ahf's idea to deprecate ContactInfo and replace it with a more > structured format instead? That could go along with the areas above > which we *actually* think should be covered by the (original) > ContactInfo field? The only negative point of removing the ContactInfo field altogether is loosing information that people put into it. >> After that I hope it sees some adoption by major operators so I can use your >> ContactInfo strings >> for automated verification and as input for malicious relay detection. > > That's one part I don't understand. You advertise the specification as > opt-in yes it is opt-in. > and relay operators are free to choose from any of the options[5] with one exception: If someone claims to adopt it, there is one mandatory field: email but the adoption in itself is still opt-in. One can still use all fields except email, it would just not be according to this draft. > but your wording above seems to imply that not following it could make > the probability higher that the relay will be marked as bad exit. I didn't think of it strictly like that but the data would obviously be usable to detect "false friends" that required manual steps in the past. false friend = malicious operators using contact info from good operators. > So, > there is supposed to happen a silent enforcement over time of an opt-in > spec which is a weird thing to me. (Additionally, what does it mean in > your spec that "The email field MUST be provided" given that the whole > spec is opt-in?) I hope my line above helps with this point. Two more resources by Eran Sandler related to this draft (not matching the latest revision): generator: https://torcontactinfogenerator.netlify.com/ parser: https://github.com/erans/torcontactinfoparser Thank you for your feedback, nusenu -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
nusenu: >> It seems to me the specification tries to make use of the fact that the >> ContactInfo field is essentially unstructured text to put things into >> it, in a slightly structured manner, that could be helpful in a number >> of areas (bad relay detection, relay metrics, network growth...). I, >> like others, fear a potential function-creep here essentially wasting >> the time you put into this important work because nobody is adopting >> your suggestions (they are opt-in according to your writing). So, my >> suggestion would be to take a step back and think harder about whether >> all of those areas would really benefit from the work in your >> specification or whether we should try to get improvements elsewhere >> going instead (E.g. I like the idea mentioned by Iain to think about new >> fields for extrainfo documents[4] for some of this information). > > It is great if you take this idea an turn it into a tor proposal with new > (extra) > descriptor fields but in the end it will require operators to adopt it > and it probably does not matter much for an operator whether the information > is > put into a single ContactInfo line or into multiple distinct lines with a > slight > plus for multiple lines for readability. > Parsing is surely cleaner with new descriptor fields. > The main point is probably to convince operators that such machine parseable > information > benefits them and the tor network (at least if you keep the opt-in spirit of > the current draft). > I mainly went for the ContactInfo field since it does not require any code > changes. Yes, that's what I figured. So, it seems to me not all your proposed keys are equally important (e.g. your require the email one). Which of those (or maybe even which cluster of those) are/is important enough in your opinion to could be considered on topic for a potential tor proposal? (If we would go that route) >> As another suggestion that could help thinking about your spec: what >> about ahf's idea to deprecate ContactInfo and replace it with a more >> structured format instead? That could go along with the areas above >> which we *actually* think should be covered by the (original) >> ContactInfo field? > > The only negative point of removing the ContactInfo field > altogether is loosing information that people put into it. Well, it does not necessarily mean losing information as the field would not just go away but be replaced by other, more narrowed down ones. Do you have some data about how the field is actually used in the wild today (I guess you did look at that before starting this proposal because it would have given you a good overview of what you would have needed to specify)? > >>> After that I hope it sees some adoption by major operators so I can use >>> your ContactInfo strings >>> for automated verification and as input for malicious relay detection. >> >> That's one part I don't understand. You advertise the specification as >> opt-in > > yes it is opt-in. > >> and relay operators are free to choose from any of the options[5] > > with one exception: If someone claims to adopt it, there is one mandatory > field: email > but the adoption in itself is still opt-in. > One can still use all fields except email, it would just not be according > to this draft. > >> but your wording above seems to imply that not following it could make >> the probability higher that the relay will be marked as bad exit. > > I didn't think of it strictly like that but the data would obviously > be usable to detect "false friends" that required manual steps in the past. > false friend = malicious operators using contact info from good operators. > >> So, >> there is supposed to happen a silent enforcement over time of an opt-in >> spec which is a weird thing to me. (Additionally, what does it mean in >> your spec that "The email field MUST be provided" given that the whole >> spec is opt-in?) > > I hope my line above helps with this point. Well, yes, at least a bit. > > Two more resources by Eran Sandler related to this draft (not matching the > latest revision): > > generator: > https://torcontactinfogenerator.netlify.com/ > > parser: > https://github.com/erans/torcontactinfoparser Thanks, that's useful. So, one thing that would be helpful here I think is getting feedback from the network-team, too, on how to move forward. I could try bringing this topic up during one of their next weekly meetings. Do you think this would be a useful thing for me to do? Georg signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
nusenu: > Georg Koppen: >> Yes, that's what I figured. So, it seems to me not all your proposed >> keys are equally important (e.g. your require the email one). Which of >> those (or maybe even which cluster of those) are/is important enough in >> your opinion to could be considered on topic for a potential tor >> proposal? (If we would go that route) > > email (if a fully automated verification process is included) Okay, that sounds like a promising start. >>> The only negative point of removing the ContactInfo field >>> altogether is loosing information that people put into it. >> Well, it does not necessarily mean losing information as the field would >> not just go away but be replaced by other, more narrowed down ones. > > which seems to imply a configuration change and not all operators will > change their configuration That might be true but we'd have some clear process ahead to phase the old field out and transition to the newer ones, and transparent ways to enforce the new model after some time. I feel that's a big plus to an optional spec that kind of exists in parallel to the status quo and might play somehow a role in determining whether a relay might get bumped out of the network or not etc. >> Do you have some data about how the field is actually used in the wild >> today > > I don't have any systematic analysis on ContactInfo strings > but if you want to take a look at them find them at the bottom of this > email sorted by cw fraction. Thanks, that's helpful. [snip] Georg signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
Hi, > On 20 Jan 2020, at 17:43, Georg Koppen wrote: > > nusenu: >> Georg Koppen: >>> Yes, that's what I figured. So, it seems to me not all your proposed >>> keys are equally important (e.g. your require the email one). Which of >>> those (or maybe even which cluster of those) are/is important enough in >>> your opinion to could be considered on topic for a potential tor >>> proposal? (If we would go that route) >> email (if a fully automated verification process is included) > > Okay, that sounds like a promising start. > The only negative point of removing the ContactInfo field altogether is loosing information that people put into it. >>> Well, it does not necessarily mean losing information as the field would >>> not just go away but be replaced by other, more narrowed down ones. >> which seems to imply a configuration change and not all operators will >> change their configuration > > That might be true but we'd have some clear process ahead to phase the > old field out and transition to the newer ones, and transparent ways to > enforce the new model after some time. > > I feel that's a big plus to an optional spec that kind of exists in > parallel to the status quo and might play somehow a role in determining > whether a relay might get bumped out of the network or not etc. If we want to recommend that operators provide an email address to stay in the consensus, we should make it easy for operators to provide an email. If we have a preferred format, we should automatically provide the email in that format. Here's a rough sketch of a spec that could work: * add a ContactEmail field to the torrc and descriptors. The field must be encoded as UTF-8. (See proposal 285 [0].) * do some minimal validation on the email field, that makes sure it looks like an email address. (Or don't, so operators can obfuscate their addresses from spammers.) And then there's a few different transition options, some of which overlap: 0. Do nothing. 1. Combine ContactEmail and ContactInfo in the descriptor's ContactInfo field, in the format that the ContactInfo spec recommends. If the email is already a substring of ContactInfo: 1.1. Do nothing. 1.2. Make sure the ContactInfo email is in the format that the ContactInfo spec recommends. 1.3. Remove the email (and the ContactInfo spec email field name) from the ContactInfo field in the descriptor, and just put it in the ContactEmail field. We could wait a few releases to make this breaking change. 2. Warn if the ContactEmail field isn't set on a relay. 3. Reject the configuration if the ContactEmail field isn't set on a relay, after a few releases. 4. Rename ContactInfo to OtherContactInfo, but allow ContactInfo as an alias for a few releases. 5. Deprecate the ContactInfo field in descriptors, and replace it with the email and other contact info fields, after distributing them in parallel for a few releases. Here's my opinion: I'd prefer no validation, combining the fields, and ensuring the email is in the ContactInfo spec format. I think we should give a config warning if the email is missing. Eventually, we should probably stop duplicating email in the ContactInfo and ContactEmail fields. (Although compression helps mitigate the impact of this kind of duplication.) I don't think we should rename ContactInfo. It is one way to force operators to eventually modify their torrc. But if we want to force a config change, let's just require that ContactEmail is set. I don't think renaming or deprecating ContactInfo in the descriptor is useful. (Renaming a field breaks a bunch of tools for no good reason. And people clearly like having an unstructured or extensible field.) But that's all just my opinion. I've run relays, and made changes to tor, but I don't work with this data every day. (Occasionally, I use it as part of selecting fallback directory mirrors.) Any proposed Tor changes should be guided by people who deal with this data all the time: the network health, bad relays, and metrics teams. (And the network team, to help with the design and implementation in Tor.) T [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
> * do some minimal validation on the email field, that makes sure it looks > like an email address. (Or don't, so operators can obfuscate their > addresses from spammers.) Please let's not add another unstructured, non-machinereadable and unverified contact field. -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
Hey, On 2020/01/20 22:25, teor wrote: > * do some minimal validation on the email field, that makes sure it looks > like an email address. (Or don't, so operators can obfuscate their > addresses from spammers.) Is the kind of obfuscation, we see in use today, for the `ContactInfo`-field useful against spammers at all? My intuition says no, but it might be wrong. I personally don't believe I've received more unwanted email by not obfuscating my email address on my relays. I think the suggestion in our man-page with generating a new email address for the relay contact information might be a better option for everybody if this is a concern to the operator. The RIPE database allows me to list the email addresses associated with various objects, if I pass some flags to their whois server, so I would assume we could add a requirement that a relay operator should use something that structurally resembles an email address at the very least. At some point in a distant future, we could even require that the email addresses are "validated" by having some service sending an email to the operator of a new relay and have them click on some link to a validation service if we think that is useful to have. All the best, Alex. -- Alexander Færøy ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
