[tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

[Nick Mathewson]

On Fri, Jul 16, 2021 at 8:31 AM Ian Goldberg <iang at 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