Send tor-dev mailing list submissions to
tor-dev@xxxxxxxxxxxxxxxxxxxx
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@lists.torproject.org
You can reach the person managing the list at
tor-dev-owner@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@xxxxxxxxx>
To: tor-dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>
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 <antitree@xxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
Message-ID:
<CAMCPh3z0Dm5_sgSCJx+k9qrzkXiwaA_uHBo6j1K3ktZD_ >HfhUQ@xxxxxxxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
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 <dgoulet@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor- dev
>
------------------------------
Message: 4
Date: Mon, 06 Nov 2017 22:35:32 +0400
From: meejah <meejah@xxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
Message-ID: <86h8u7gsqz.fsf@atlantis.meejah.ca >
Content-Type: text/plain; charset=us-ascii
David Goulet <dgoulet@xxxxxxxxx> 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@xxxxxxxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx>
Date: Mon, Nov 6, 2017 at 3:41 PM
Subject: Nyx 2.0 Release
To: tor-relays@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@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev