On Fri, Jul 16, 2021 at 8:31 AM Ian Goldberg <i...@uwaterloo.ca> wrote: [...] > But this post from Trevor also made me realize a bigger issue with the > protocol Nick proposed: > > If you want the protocol to work with Walking Onions, it needs to be > *post-specified peer*. That is, contrary to: > > > The client knows: > > * B: a public "onion key" for S > > The client will in fact _not_ know B in advance in a Walking Onions > setting, but rather will learn it at the end of the handshake. The > protocol Nick specified does in fact use B in the first message, unlike > the current ntor handshake, which just sends KEYID(B) in the first flow, > but it's not part of the math, or indeed as far as I can see, used for > anything at all in Section 5.1.4 of tor-spec.txt, and so can be easily > removed (and replaced with B being sent by the server) for Walking > Onions.
Well, in the current deployment, the client only knows one B for each server at a time, and if the server responds with a B that the client _doesn't_ recognize, the client won't have any idea whether or not B is really authentic. (Priving that B is authentic is a big part of what Walking Onions has to solve.) Walking Onions is a big enough set of protocol changes that I'm comfortable requiring a subsequent handshake bump when we get there. Who knows, we may want another one between now and then if we decide to go hybrid-PQ or use Noise or something :) cheers, -- Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev