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