[tor-dev] Reviewing prop224 fixes

[David Goulet]

On 04 Apr (13:07:29), George Kadianakis wrote:
> 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.

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160405/6da088f2/attachment.sig>