unsubscribe On Tue, Nov 7, 2017 at 11:12 AM, <tor-dev-requ...@lists.torproject.org> wrote:
> Send tor-dev mailing list submissions to > tor-dev@lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-requ...@lists.torproject.org > > You can reach the person managing the list at > tor-dev-ow...@lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Proposal 284: Hidden Service v3 Control Port (David Goulet) > 2. Re: Proposal 284: Hidden Service v3 Control Port (AntiTree) > 3. Re: Proposal 284: Hidden Service v3 Control Port (Damian Johnson) > 4. Re: Proposal 284: Hidden Service v3 Control Port (meejah) > 5. Fwd: Nyx 2.0 Release (Damian Johnson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Nov 2017 09:59:07 -0500 > From: David Goulet <dgou...@ev0ke.net> > To: tor-dev <tor-dev@lists.torproject.org> > Subject: [tor-dev] Proposal 284: Hidden Service v3 Control Port > Message-ID: <20171106145907.p7dm7dmqpnzlqsmj@raoul> > Content-Type: text/plain; charset="utf-8" > > Hi everyone, > > Attached is the proposal draft for the hidden service v3 contro port > specification. > > The idea with this proposal is to _only_ extend the current commands and > events to v3. Nothing new is added. We can think of more things to add > after > but for now, I wanted a baseline to start with that is only extending what > exists. > > Any kind of feedbacks is welcome! :) > > Cheers! > David > > -- > Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= > -------------- next part -------------- > Filename: 284-hsv3-control-port.txt > Title: Hidden Service v3 Control Port > Author: David Goulet > Created: 02-November-2017 > Status: Open > > 1. Summary > > This document extends the hidden service control port events and > commands > to version 3 (rend-spec-v3.txt). > > No command nor events are newly added in this document, it only desribes > how the current commands and events are extended to support v3. > > 2. Format > > The formatting of this document follows section 2 of control-spec.txt. > It > is split in two sections, the Commands and the Events for hidden service > version 3. > > We define the alphabet of a Base64 encoded value to be: > > Base64Character = "A"-"Z" / "a"-"z" / "0"-"9" / "+" / "/" > > For a command or event, if nothing is mentionned, the behavior doesn't > change from the control port specification. > > 3. Specification: > > 3.1. Commands > > As specified in the control specification, all commands are > case-insensitive but the keywords are case-sensitive. > > 3.1.1. GETINFO > > Hidden service commands are: > > "hs/client/desc/id/<ADDR>" > The <ADDR> can be a v3 address without the ".onion" part. The rest > is > as is. > > "hs/service/desc/id/<ADDR>" > The <ADDR> can be a v3 address without the ".onion" part. The rest > is > as is. > > "onions/{current,detached}" > No change. This command can support v3 hidden service without > changes > returning v3 address(es). > > 3.1.2. HSFETCH > > The syntax of this command supports both an HSAddress or a versionned > descriptor ID. However, for descriptor ID, version 3 doesn't have the > same > concept as v2 so, for v3 the descriptor ID is the blinded key of a > descriptor which is used as an index to query the HSDir: > > The syntax becomes: > "HSFETCH" SP (HSAddress / "v" Version "-" DescId) > *[SP "SERVER=" Server] CRLF > > HSAddress = (16*Base32Character / 56*Base32Character) > Version = "2" / "3" > DescId = (32*Base32Character / 32*Base64Character) > Server = LongName > > The "HSAddress" key is extended to accept 56 base32 characters which is > the > format of a version 3 onion address. > > The "DescId" of the form 32*Base64Character is the descriptor blinded > key > used as an index to query the directory. It can only be used with > "Version=3". > > 3.1.5. HSPOST > > No change. This command can support v3 hidden service without changes. > > 3.1.3. ADD_ONION > > For this command to support version 3, new values are added but the > syntax > is unchanged: > > "ADD_ONION" SP KeyType ":" KeyBlob > [SP "Flags=" Flag *("," Flag)] > 1*(SP "Port=" VirtPort ["," Target]) > *(SP "ClientAuth=" ClientName [":" ClientBlob]) CRLF > > New "KeyType" value to "ED25519-V3" which identifies the key type to be > a > v3 ed25519 key. > > New "KeyBlob" value to support the new "ED25519-V3", if specified, will > generate a new ed25519 private key. > > Because client authentication is not yet implemented, the "ClientAuth" > field is ignored as well as "Flags=BasicAuth". > > 3.1.4. DEL_ONION > > The syntax of this command is: > > "DEL_ONION" SP ServiceID CRLF > > ServiceID = The Onion Service address without the trailing ".onion" > suffix > > The "ServiceID" can simply be a v3 address. Nothing else changes. > > 3.2. Events > > 3.2.1. HS_DESC > > For this event to support vesrion 3, one optional field and new > values are added: > > "650" SP "HS_DESC" SP Action SP HSAddress SP AuthType SP HsDir > [SP DescriptorID] [SP "REASON=" Reason] [SP "REPLICA=" Replica] > [SP "HSDIR_INDEX=" HSDirIndex] > > Action = "REQUESTED" / "UPLOAD" / "RECEIVED" / "UPLOADED" / "IGNORE" > / > "FAILED" / "CREATED" > HSAddress = 16*Base32Character / 56*Base32Character / "UNKNOWN" > AuthType = "NO_AUTH" / "BASIC_AUTH" / "STEALTH_AUTH" / "UNKNOWN" > HsDir = LongName / Fingerprint / "UNKNOWN" > DescriptorID = 32*Base32Character / 32*Base64Character > Reason = "BAD_DESC" / "QUERY_REJECTED" / "UPLOAD_REJECTED" / > "NOT_FOUND" / > "UNEXPECTED" / "QUERY_NO_HSDIR" > Replica = 1*DIGIT > HSDirIndex = 64*HEXDIG > > The "HSDIR_INDEX=" is an optional field that is only for version 3 which > contains the computed index of the HsDir the descriptor was uploaded to > or > fetched from. > > The "HSAddress" key is extended to accept 56 base32 characters which is > the > format of a version 3 onion address. > > The "DescriptorID" key is extended to accept 32 base64 characters which > is > the descriptor blinded key used for the index value at the "HsDir". > > Because client authentication is not yet implemented, the "AuthType" > field > is always "NO_AUTH". > > 3.2.2. HS_DESC_CONTENT > > For this event to support version 3, new values are added but the > syntax is > unchanged: > > "650" "+" "HS_DESC_CONTENT" SP HSAddress SP DescId SP HsDir CRLF > Descriptor CRLF "." CRLF "650" SP "OK" CRLF > > HSAddress = 16*Base32Character / 56*Base32Character / "UNKNOWN" > DescId = 32*Base32Character / 32*Base64Character > HsDir = LongName / "UNKNOWN" > Descriptor = The text of the descriptor formatted as specified in > rend-spec-v3.txt section 2.4 or empty string on failure. > > The "HSAddress" key is extended to accept 56 base32 characters which is > the > format of a version 3 onion address. > > The "DescriptorID" key is extended to accept 32 base64 characters which > is > the descriptor blinded key used for the index value at the "HsDir". > > 3.2.3 CIRC and CIRC_MINOR > > These circuit events have an optional field named "REND_QUERY" which > takes > an "HSAddress". This field is extended to support v3 address: > > HSAddress = 16*Base32Character / 56*Base32Character / "UNKNOWN" > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 455 bytes > Desc: not available > URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/ > 20171106/1234e42b/attachment-0001.sig> > > ------------------------------ > > Message: 2 > Date: Mon, 06 Nov 2017 15:44:26 +0000 > From: AntiTree <antit...@gmail.com> > To: tor-dev@lists.torproject.org > Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port > Message-ID: > <CAMCPh3z0Dm5_sgSCJx+k9qrzkXiwaA_uHBo6j1K3ktZD_ > hf...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hey David, > > Are there any ways of revoking a service's key and should it be included as > a control port function? For example, in the case that the master key is > kept offline but the host and its descriptor signing key are compromised, > the box could be run for a period of time(?) until the keys expire and need > to be re-signed. That window could be forcefully closed remotely with a > revocation that reports that key as compromised. I don't know how big that > window is so I don't know how big of a risk it ends up being. > > @ > > On Mon, Nov 6, 2017 at 9:59 AM David Goulet <dgou...@ev0ke.net> wrote: > > > Hi everyone, > > > > Attached is the proposal draft for the hidden service v3 contro port > > specification. > > > > The idea with this proposal is to _only_ extend the current commands and > > events to v3. Nothing new is added. We can think of more things to add > > after > > but for now, I wanted a baseline to start with that is only extending > what > > exists. > > > > Any kind of feedbacks is welcome! :) > > > > Cheers! > > David > > > > -- > > Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= > > _______________________________________________ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/ > 20171106/e120b0d6/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Mon, 6 Nov 2017 10:15:18 -0800 > From: Damian Johnson <ata...@torproject.org> > To: tor-dev@lists.torproject.org > Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port > Message-ID: > <CAJdkzEM-7SNN8JhN+93_5uFkvJ_vZRLRWCfRv4ATaCUBGYxNPQ@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi David, great proposal! Sorry I'm juggling too many things right now > to really really review it. Quick skim though looks great. One quick > thought is that the HS_DESC event has an optional positional argument > (DescriptorID). This is fine *but* I'd advise against it since it will > prevent you from ever adding more positional arguments in the future. > Making it a key=value argument instead sidesteps this. > > > On Mon, Nov 6, 2017 at 6:59 AM, David Goulet <dgou...@ev0ke.net> wrote: > > Hi everyone, > > > > Attached is the proposal draft for the hidden service v3 contro port > > specification. > > > > The idea with this proposal is to _only_ extend the current commands and > > events to v3. Nothing new is added. We can think of more things to add > after > > but for now, I wanted a baseline to start with that is only extending > what > > exists. > > > > Any kind of feedbacks is welcome! :) > > > > Cheers! > > David > > > > -- > > Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= > > > > _______________________________________________ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > > ------------------------------ > > Message: 4 > Date: Mon, 06 Nov 2017 22:35:32 +0400 > From: meejah <mee...@meejah.ca> > To: tor-dev@lists.torproject.org > Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port > Message-ID: <86h8u7gsqz....@atlantis.meejah.ca> > Content-Type: text/plain; charset=us-ascii > > David Goulet <dgou...@ev0ke.net> writes: > > Hi David, > > Overall looks good! A few comments inline: > > > "onions/{current,detached}" > > No change. This command can support v3 hidden service without > changes > > returning v3 address(es). > > Does the control-spec need a note pointing out that you might get some > "longer" (v3) addresses? > > > 3.1.3. ADD_ONION > > > > For this command to support version 3, new values are added but the > syntax > > is unchanged: > > > > "ADD_ONION" SP KeyType ":" KeyBlob > > [SP "Flags=" Flag *("," Flag)] > > 1*(SP "Port=" VirtPort ["," Target]) > > *(SP "ClientAuth=" ClientName [":" ClientBlob]) CRLF > > > > New "KeyType" value to "ED25519-V3" which identifies the key type to > be a > > v3 ed25519 key. > > > > New "KeyBlob" value to support the new "ED25519-V3", if specified, > will > > generate a new ed25519 private key. > > This might need a couple more details; as-is ADD_ONION can take > "NEW:BEST" (which should now return a v3 service?) or "NEW:ED25519-V3" > for explicitly asking for a V3 key, or "ED25519-V3:<56 base32 chars>" > for adding an already-existing v3 service. > > > Because client authentication is not yet implemented, the "ClientAuth" > > field is ignored as well as "Flags=BasicAuth". > > I think these should generate a 500-level error (if used for a v3 > service) instead of being ignored. That is, if you try to use auth with > v3, you get an error. > > > For this event to support vesrion 3, one optional field and new > > values are added: > > I echo Damian's comments on the positional-arg; making it [SP > "DescriptorID=" ] or similar (i.e. an optional kwarg) would mean easier > later extending and also it *should* then "just work" with most > controller libs already at least as far as parsing goes (because > controller libs in general have to accept new, unknown kwargs). > > > The rest all sounds good to me! > > thanks, > meejah > > > ------------------------------ > > Message: 5 > Date: Mon, 6 Nov 2017 16:12:51 -0800 > From: Damian Johnson <ata...@torproject.org> > To: tor-dev@lists.torproject.org > Subject: [tor-dev] Fwd: Nyx 2.0 Release > Message-ID: > <CAJdkzENPe6hOpoBSmrj5Ax-_wFBBtVuX2aB5KaW7bBjvqMZB1Q@ > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi tor-dev. Sorry for the cross post but while tor-relays@ is the > perfect spot to announce Nyx, tor-dev@ is the traditional place to > unveil Stem. > > I'm pleased to announce Stem 1.6, the accumulation of a full year of > improvements for our controller library... > > https://stem.torproject.org/change_log.html#version-1-6 > > Besides features such as descriptor creation and ed25519 support the > main highlight for this release is performance tuning. Descriptor > parsing is ~25% faster and low-level control socket handling got some > special attention. > > Cheers! -Damian > > ---------- Forwarded message ---------- > From: Damian Johnson <ata...@torproject.org> > Date: Mon, Nov 6, 2017 at 3:41 PM > Subject: Nyx 2.0 Release > To: tor-rel...@lists.torproject.org > > > Hi all, after years of being in the works I'm pleased to announce Nyx! > A long overdue modernization of arm. > > http://blog.atagar.com/nyx-release-2-0/ > https://nyx.torproject.org/ > > Even more important for our controller space at large, Nyx is coming > hand-in-hand with Stem 1.6. A full year of improvements that include > descriptor creation support, ed25519 certificates, performance tuning, > and much, much more... > > https://stem.torproject.org/change_log.html#version-1-6 > > Cheers! -Damian > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > ------------------------------ > > End of tor-dev Digest, Vol 82, Issue 8 > ************************************** >
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
