[tor-dev] Proposal 284: Hidden Service v3 Control Port

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.

@

Post by David Goulet
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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

David Goulet

2017-11-07 17:22:33 UTC

Post by AntiTree
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.

To have a revocation system like that, we need some sort of mechanism that
remembers revoked keys at maybe the directory level of as a complete new
entity that keeps a registry of those.

We do not have a way to do that nor a proposal for it :S...

David

Post by AntiTree
@

_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=

Damian Johnson

2017-11-06 18:15:18 UTC

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.

David Goulet

2017-11-07 17:10:48 UTC

Post by Damian Johnson
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.

What do you propose exactly? I can't really change the "DescriptorID" to a
key=value format. So, you think I should just not extend that field and use a
new "key=value" for it?

Thanks!
David

_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=

Damian Johnson

2017-11-07 17:40:36 UTC

Post by David Goulet
What do you propose exactly?

Hi David. What I mean is that having an optional positional field...

MyEvent Field1 Field2 [Field3] Key1=Value1

... means we cannot ever add more positional fields in the future. For
example...

MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1

... would be ambiguous if the third field is Field3 or Field4 since
they're both optional. We also could not add new mandatory positional
fields...

MyEvent Field1 Field2 Field4 [Field3] Key1=Value1

... because it would be ambiguous if the third field was Field4 with a
new version of tor or Field3 with an old one.

Post by David Goulet
I can't really change the "DescriptorID" to a
key=value format. So, you think I should just not extend that field and use a
new "key=value" for it?

Why not? Does the DescriptorID have equal signs in it? If so then you
could also make this be a mandatory positional field with a filler
value like 'none' if unavailable.

Cheers! -Damian

David Goulet

2017-11-07 17:47:43 UTC

Post by David Goulet
What do you propose exactly?

Hi David. What I mean is that having an optional positional field...
MyEvent Field1 Field2 [Field3] Key1=Value1
... means we cannot ever add more positional fields in the future. For
example...
MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1
... would be ambiguous if the third field is Field3 or Field4 since
they're both optional. We also could not add new mandatory positional
fields...
MyEvent Field1 Field2 Field4 [Field3] Key1=Value1
... because it would be ambiguous if the third field was Field4 with a
new version of tor or Field3 with an old one.

Post by David Goulet
I can't really change the "DescriptorID" to a
key=value format. So, you think I should just not extend that field and use a
new "key=value" for it?

Why not? Does the DescriptorID have equal signs in it? If so then you
could also make this be a mandatory positional field with a filler
value like 'none' if unavailable.

Oh! I guess we aren't breaking backward compat. by changing DescriptorID field
because it is optional in the first place so all future version will simply
never use it and only use the new "DescriptorID=<value>" field instead.

Thanks!
David

Post by Damian Johnson
Cheers! -Damian
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=

David Goulet

2017-11-07 19:43:31 UTC

Post by David Goulet
What do you propose exactly?

Hi David. What I mean is that having an optional positional field...
MyEvent Field1 Field2 [Field3] Key1=Value1
... means we cannot ever add more positional fields in the future. For
example...
MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1
... would be ambiguous if the third field is Field3 or Field4 since
they're both optional. We also could not add new mandatory positional
fields...
MyEvent Field1 Field2 Field4 [Field3] Key1=Value1
... because it would be ambiguous if the third field was Field4 with a
new version of tor or Field3 with an old one.

Post by David Goulet
I can't really change the "DescriptorID" to a
key=value format. So, you think I should just not extend that field and use a
new "key=value" for it?

Why not? Does the DescriptorID have equal signs in it? If so then you
could also make this be a mandatory positional field with a filler
value like 'none' if unavailable.

Not entirely true actually, if we do that, the old Stem won't be able to
pickup the descriptor ID from new Tor... So how do you suggest to proceed with
backward compat? Just a new field like "DESCRIPTOR_ID=" and we leave the
"DescriptorID" in duplicating the information for v2 descriptors? Kinda seems
weird.

David

Post by David Goulet
Thanks!
David

Post by Damian Johnson
Cheers! -Damian
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=

Damian Johnson

2017-11-07 19:59:25 UTC

Post by David Goulet
Not entirely true actually, if we do that, the old Stem won't be able to
pickup the descriptor ID from new Tor... So how do you suggest to proceed with
backward compat? Just a new field like "DESCRIPTOR_ID=" and we leave the
"DescriptorID" in duplicating the information for v2 descriptors? Kinda seems
weird.

Hi David. Meejah was right that there seems to be a misunderstanding
here. I only commented about it because the DESCRIPTOR_ID was part of
your proposal. If it's just citing an existing part of the spec then
no worries. :)

meejah

2017-11-07 17:58:02 UTC

Post by David Goulet
What do you propose exactly?

Hi David. What I mean is that having an optional positional field...

I think the missing fact here is that there is *already* the
DescriptorID field and it's already optional (in the current
control-spec).

--
meejah

meejah

2017-11-07 17:54:11 UTC

Post by Damian Johnson
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.

What do you propose exactly? I can't really change the "DescriptorID"
to a key=value format. So, you think I should just not extend that
field and use a new "key=value" for it?

Ahhh, I see what you mean: DescriptorID is *already* in the spec for
HS_DESC as an (optional) positional argument -- you're just extending it
to accept possibly more characters?

So, yes, just making it "possibly bigger" is fine IMO. In other words,
we've already baked into the spec the thing Damian doesn't want (an
optional positional arg) so there's not really any way out of that.

--
meejah

meejah

2017-11-06 18:35:32 UTC

David Goulet <***@ev0ke.net> writes:

Hi David,

"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
"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

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

David Goulet

2017-11-07 17:20:15 UTC

Post by Damian Johnson
Hi David,

"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?

Yes, once this proposal is merged to control-spec.txt, it will mention it for
sure what to expect.

Oh good point! I failed to notice that "RSA1024:<key>" was even possible.
Actually, it is not specified in the spec but the code expects this:

"RSA1024:<Base64 Blob>" - Loading a pre-existing RSA1024 key.

Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.

To be consistent then we could ask for a <Base64 Blob> as well:

"ED25519-V3:<Base64 Blob>"

... which contains the ed25519 private key.

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.

Indeed.

I'm unsure between
"512 Syntax error in command argument"

"552 Unrecognized entity"
[A configuration key, a stream ID, circuit ID, event,
mentioned in the command did not actually exist.]

But overall yes!

For this event to support vesrion 3, one optional field and new

See other thread about this.

Big thanks!
David

Post by Damian Johnson
The rest all sounds good to me!
thanks,
meejah
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=

meejah

2017-11-07 17:48:21 UTC

Post by David Goulet
Indeed.
I'm unsure between
"512 Syntax error in command argument"
"552 Unrecognized entity"
[A configuration key, a stream ID, circuit ID, event,
mentioned in the command did not actually exist.]
But overall yes!

It looks like the previous code would have done a 512 (when ADD_ONION
existed but didn't support authentication yet) so that's probably good
here too.

...but, maybe "513 Unrecognized command argument" would be a good
candidate, too?

...or even a new one for this case (and future cases) of "recognized,
but not yet supported". "560 Not yet implemented" or similar?

--
meejah

meejah

2017-11-09 04:50:21 UTC

Post by David Goulet
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

Maybe it's too late, but it would be nice if the hs_ed25519_secret_key
file was encoded in base64 as well (instead of binary) to facilitate
copying them (if, e.g. you're upgrading from an on-disk v3 service to an
ADD_ONION v3 service)

cheers,

--
meejah

teor

2017-11-09 09:10:01 UTC

Post by meejah

This might need a couple more details; as-is ADD_ONION can take
"NEW:BEST" (which should now return a v3 service?)

When we change the default HiddenServiceVersion to 3, then let's make
BEST return a v3 service. Until then, let's make it v2.

I think it would be a good idea to be consistent like this.

T

Post by meejah
or "NEW:ED25519-V3"
for explicitly asking for a V3 key, or "ED25519-V3:<56 base32 chars>"
for adding an already-existing v3 service.

Oh good point! I failed to notice that "RSA1024:<key>" was even possible.
"RSA1024:<Base64 Blob>" - Loading a pre-existing RSA1024 key.
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

Yawning Angel

2017-11-09 09:27:15 UTC

On Tue, 7 Nov 2017 12:20:15 -0500

Post by meejah
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.

Oh good point! I failed to notice that "RSA1024:<key>" was even
possible. Actually, it is not specified in the spec but the code
"RSA1024:<Base64 Blob>" - Loading a pre-existing RSA1024 key.

Huh? It *is* specified, both as "intentionally opaque" and as a
detailed explanation of what the code actually expects, like thus:

(The KeyBlob format is left intentionally opaque, however for
"RSA1024" keys it is currently the Base64 encoded DER representation
of a PKCS#1 RSAPrivateKey, with all newlines removed.)

Post by David Goulet
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

If it were up to me, I'd spec the blob as opaque, and then actually use
something that's sensible and consistent with the torrc and on disk
files for easy interoperability like Base64 of the private key (I
haven't check to see what encoding is used for on disk EdDSA keys, I
assume PEM).

Regards,

--
Yawning Angel

David Goulet

2017-11-09 15:13:45 UTC

Post by Yawning Angel
On Tue, 7 Nov 2017 12:20:15 -0500

Oh good point! I failed to notice that "RSA1024:<key>" was even
possible. Actually, it is not specified in the spec but the code
"RSA1024:<Base64 Blob>" - Loading a pre-existing RSA1024 key.

Huh? It *is* specified, both as "intentionally opaque" and as a
(The KeyBlob format is left intentionally opaque, however for
"RSA1024" keys it is currently the Base64 encoded DER representation
of a PKCS#1 RSAPrivateKey, with all newlines removed.)

Oh I didn't spot that far away from the "KeyBlob" :).

Post by David Goulet
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

Unfortunately not, it is custom to tor I believe with this 32 bytes header:

"== ed25519v1-secret: type0 ==\0\0\0"

... followed by the private key (64 bytes). See
crypto_write_tagged_contents_to_file().

Not sure we can change that within the 032 freeze. So the approach would be to
Base64 the raw bytes of the key (excluding the header). Using tor HS key file,
it would be something like:

$ tail -c+33 hs_ed25519_secret_key | base64 -w 0

Considering the current situation with the encoded file on disk of the key, I
think this is kind of the simplest approach?

Cheers!
David

Post by Yawning Angel
Regards,
--
Yawning Angel
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=

Yawning Angel

2017-11-09 16:17:02 UTC

On Thu, 9 Nov 2017 10:13:45 -0500

Post by David Goulet
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

If it were up to me, I'd spec the blob as opaque, and then actually
use something that's sensible and consistent with the torrc and on
disk files for easy interoperability like Base64 of the private key
(I haven't check to see what encoding is used for on disk EdDSA
keys, I assume PEM).

"== ed25519v1-secret: type0 ==\0\0\0"
... followed by the private key (64 bytes). See
crypto_write_tagged_contents_to_file().
Not sure we can change that within the 032 freeze. So the approach
would be to Base64 the raw bytes of the key (excluding the header).
$ tail -c+33 hs_ed25519_secret_key | base64 -w 0
Considering the current situation with the encoded file on disk of
the key, I think this is kind of the simplest approach?

Yeah. Just the Base64ed private key (excluding that header and things)
seems reasonable.

--
Yawning Angel

teor

2017-11-09 17:06:55 UTC

Post by Yawning Angel
On Thu, 9 Nov 2017 10:13:45 -0500

Post by David Goulet
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

If it were up to me, I'd spec the blob as opaque, and then actually
use something that's sensible and consistent with the torrc and on
disk files for easy interoperability like Base64 of the private key
(I haven't check to see what encoding is used for on disk EdDSA
keys, I assume PEM).

Show Quoted Content

Post by David Goulet
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

If it were up to me, I'd spec the blob as opaque, and then actually
use something that's sensible and consistent with the torrc and on
disk files for easy interoperability like Base64 of the private key
(I haven't check to see what encoding is used for on disk EdDSA
keys, I assume PEM).

Yeah. Just the Base64ed private key (excluding that header and things)
seems reasonable.

Do we accept base64 with padding? Without padding?
(We should accept both - we know how long the key is.)

Do we generate it with or without padding?
(We should follow whatever we do with RSA.)

T

David Goulet

2017-11-09 17:14:01 UTC

Post by teor

Post by Yawning Angel
On Thu, 9 Nov 2017 10:13:45 -0500

Post by David Goulet
Ok fun! I'll add this. Good catch! And control-spec.txt should be updated.
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.

If it were up to me, I'd spec the blob as opaque, and then actually
use something that's sensible and consistent with the torrc and on
disk files for easy interoperability like Base64 of the private key
(I haven't check to see what encoding is used for on disk EdDSA
keys, I assume PEM).

Show Quoted Content