[tor-dev] tor-dev Digest, Vol 82, Issue 8
Nathan Kettle
nathan.kettle93 at gmail.com
Tue Nov 7 00:42:08 UTC 2017
unsubscribe
On Tue, Nov 7, 2017 at 11:12 AM, <tor-dev-request at lists.torproject.org>
wrote:
> Send tor-dev mailing list submissions to
> tor-dev at 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-request at lists.torproject.org
>
> You can reach the person managing the list at
> tor-dev-owner at 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 <dgoulet at ev0ke.net>
> To: tor-dev <tor-dev at lists.torproject.org>
> Subject: [tor-dev] Proposal 284: Hidden Service v3 Control Port
> Message-ID: <20171106145907.p7dm7dmqpnzlqsmj at 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 <antitree at gmail.com>
> To: tor-dev at lists.torproject.org
> Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
> Message-ID:
> <CAMCPh3z0Dm5_sgSCJx+k9qrzkXiwaA_uHBo6j1K3ktZD_
> HfhUQ at 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 <dgoulet at 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 at 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 <atagar at torproject.org>
> To: tor-dev at lists.torproject.org
> Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
> Message-ID:
> <CAJdkzEM-7SNN8JhN+93_5uFkvJ_vZRLRWCfRv4ATaCUBGYxNPQ at 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 <dgoulet at 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 at 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 <meejah at meejah.ca>
> To: tor-dev at lists.torproject.org
> Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
> Message-ID: <86h8u7gsqz.fsf at atlantis.meejah.ca>
> Content-Type: text/plain; charset=us-ascii
>
> David Goulet <dgoulet at 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 <atagar at torproject.org>
> To: tor-dev at 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 <atagar at torproject.org>
> Date: Mon, Nov 6, 2017 at 3:41 PM
> Subject: Nyx 2.0 Release
> To: tor-relays at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
> ------------------------------
>
> End of tor-dev Digest, Vol 82, Issue 8
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171107/47568b14/attachment-0001.html>
More information about the tor-dev
mailing list