[tor-dev] Reviewing prop224 fixes

[George Kadianakis]

John Brooks <john.brooks at dereferenced.net> writes:

> [ text/plain ]
> (Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
>
>> On Mar 17, 2016, at 7:29 PM, George Kadianakis <desnacked at riseup.net> wrote:
>> 
>> Also, please see my torspec branch `prop224-fixes` for some torspec changes on prop224.
>> My branch is sitting on top of the prop224 branch of special/dgoulet.
>> 
>> You can see it here: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes
>> 
>
> Some trivial comments (reading from 1dd4bff6):
>
> dcb5e79e649c35ee2379ba38f112ddbd3b117362
>
> +   status back to the hidden service host with an empty INTRO_ESTABLISHED
> +   cell. The INTRO_ESTABLISHED cell has the following contents:
>
> Strike “empty”
>
> aced690def0867597b180e817e57ebd14f64703f
>
> Removing the key length field excludes parsing cells containing unknown key types. I
> can’t see that being a problem for any of the cells where this is used, though - they’d fail
> on unknown key types anyway. Should be ok I guess.
>
> 9d79d6ad76b6126cd3616bfdec10b14a413d9d02
>
> +   The PROTOID for this variant is "hidden-service-ntor-curve25519-sha256-1”.
>
> We are not using sha256 here anymore.
>

OK I addressed the comments above in my branch `prop224-fixes`.
I also ripped out the MAINT_INTRO command as was discussed. 

Please see: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes

(I didn't change the key type thing you pointed out. Not sure if changing it to
the old type / len / key architecture would make things better. Please let me
know if you decide it will.)

> 442f0b3791797ebbac3feb2bffb87318fe8d84 "Clarify prop224 use of shared random”
>
> Seems like we will need a lot more detail on how the shared random values are used
> for the hash ring, the process for switching to the new SRV, and so on. Is somebody
> planning to write that up? Has it all been decided yet?
>

Agreed. Looking at the time period logic is next on my stack, and my plan is to
make another thread similar to this one.

>> 
>> Stuff I need to look into next:
>> - Can we simplify the backwards compat logic?
>> - Should we add extensions to the rendezvous cells (at the cost of failing backwards compat)?
>> - Address more TODOs (there are a bunch of hard ones in there).
>> - Clean up some messy sections.
>> - Figure out the fate of UPDATE-KEYS-SUBCMD (see my previous mail).
>
> Happy to discuss any of these any time. My list right now is:
>
> - Look at onion hostnames, figure out the extra 4 bits and potentially a checksum
> - Fix client authentication
> - Thinking more about denial of service, especially on hsdirs
>

Sounds good. Let me know when you have thoughts or patches.