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

[David Goulet]

On 10 Nov (04:06:55), teor wrote:
> 
> > On 10 Nov 2017, at 03:17, Yawning Angel  wrote:
> > 
> > On Thu, 9 Nov 2017 10:13:45 -0500
> > David Goulet  wrote:
>  Ok fun! I'll add this. Good catch! And control-spec.txt should be
>  updated.
>  
>  To be consistent then we could ask for a  as well:
>  
> "ED25519-V3:"
>  
>  ... 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).  
> >> 
> >> 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?
> > 
> > Show Quoted Content
>  Ok fun! I'll add this. Good catch! And control-spec.txt should be
>  updated.
>  
>  To be consistent then we could ask for a  as well:
>  
> "ED25519-V3:"
>  
>  ... 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).  
> >> 
> >> 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?
> > 
> > 
> > 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.)

It follows the tor base64 API so basically padding is added when encoding and
padding or not when decoding is working.

Because we know the size of the keys, tor expects a specific byte size
(padding or not).

This is what the RSA base64 encoding/decoding does.

David

> 
> T

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


-- 
jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

> On 10 Nov 2017, at 03:17, Yawning Angel  wrote:
> 
> On Thu, 9 Nov 2017 10:13:45 -0500
> David Goulet  wrote:
 Ok fun! I'll add this. Good catch! And control-spec.txt should be
 updated.
 
 To be consistent then we could ask for a  as well:
 
"ED25519-V3:"
 
 ... 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).  
>> 
>> 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?
> 
> Show Quoted Content
 Ok fun! I'll add this. Good catch! And control-spec.txt should be
 updated.
 
 To be consistent then we could ask for a  as well:
 
"ED25519-V3:"
 
 ... 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).  
>> 
>> 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?
> 
> 
> 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___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Yawning Angel]

On Thu, 9 Nov 2017 10:13:45 -0500
David Goulet  wrote:
> > > Ok fun! I'll add this. Good catch! And control-spec.txt should be
> > > updated.
> > > 
> > > To be consistent then we could ask for a  as well:
> > > 
> > > "ED25519-V3:"
> > > 
> > > ... 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).  
> 
> 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?

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

-- 
Yawning Angel


pgpRS2OrGZWk9.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 09 Nov (09:27:15), Yawning Angel wrote:
> On Tue, 7 Nov 2017 12:20:15 -0500
> David Goulet  wrote:
> > > 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:" was even
> > possible. Actually, it is not specified in the spec but the code
> > expects this:
> > 
> > "RSA1024:" - 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.)

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

> 
> > Ok fun! I'll add this. Good catch! And control-spec.txt should be
> > updated.
> > 
> > To be consistent then we could ask for a  as well:
> > 
> > "ED25519-V3:"
> > 
> > ... 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).

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

> 
> Regards,
> 
> -- 
> Yawning Angel



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


-- 
jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

On 8 Nov 2017, at 04:20, David Goulet  wrote:

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

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

>> 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:" was even possible.
> Actually, it is not specified in the spec but the code expects this:
> 
>"RSA1024:" - 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  as well:
> 
>"ED25519-V3:"
> 
> ... which contains the ed25519 private key.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[meejah]

David Goulet  writes:

> To be consistent then we could ask for a  as well:
>
> "ED25519-V3:"
>
> ... 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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Damian Johnson]

> 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. :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 07 Nov (12:47:43), David Goulet wrote:
> On 07 Nov (09:40:36), Damian Johnson wrote:
> > > 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.
> > 
> > > 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=" field instead.

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

> 
> Thanks!
> David
> 
> > 
> > Cheers! -Damian
> > ___
> > tor-dev mailing list
> > tor-dev@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> -- 
> 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=



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


-- 
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[meejah]

David Goulet  writes:
> On 06 Nov (10:15:18), Damian Johnson wrote:

>> 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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[meejah]

David Goulet  writes:

> 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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 07 Nov (09:40:36), Damian Johnson wrote:
> > 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.
> 
> > 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=" field instead.

Thanks!
David

> 
> Cheers! -Damian
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Damian Johnson]

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

> 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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 06 Nov (15:44:26), AntiTree wrote:
> 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

> 
> @
> 
> On Mon, Nov 6, 2017 at 9:59 AM David Goulet  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
> >

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


-- 
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 06 Nov (22:35:32), meejah wrote:
> David Goulet  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?

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

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

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

"RSA1024:" - 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  as well:

"ED25519-V3:"

... 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
> >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).

See other thread about this.

Big thanks!
David

> 
> The rest all sounds good to me!
> 
> thanks,
> meejah
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[David Goulet]

On 06 Nov (10:15:18), Damian Johnson wrote:
> 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

> 
> 
> On Mon, Nov 6, 2017 at 6:59 AM, David Goulet  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
> >
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[meejah]

David Goulet  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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[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.


On Mon, Nov 6, 2017 at 6:59 AM, David Goulet  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
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[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.

@

On Mon, Nov 6, 2017 at 9:59 AM David Goulet  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
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev