[tor-dev] Reviewing prop224 fixes

[John Brooks]

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

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?

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

Cheers,

- special
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160331/73303769/attachment.sig>