On 04 Apr (13:07:29), George Kadianakis wrote: > John Brooks <john.brooks@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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. I'm happy with the current changes! I say you can merge them upstream in torspec or wait for a nickm/roger ack :) Cheers! David > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev