"Attack" on PFS in tor-spec

[Paul Syverson <syverson@itd.nrl.navy.mil>]

Something Roger and I were talking about:

So I found a handwritten note on a printout dated July 11 of the
end-April tor-spec outline with the following observation: if we allow
OR_2 to send back an unencrypted EXTENDED cell with contents g^Y, then
the previous node in the circuit, OR_1, will be able to substitute a
different g^Y and hijack the session. No big deal, the hijacker won't
actually be able to read any traffic since he won't have g^X.  The
only thing is that, without authenticating the g^Y somehow, if the
client sends any stuff under g^XY, (maybe an EXTEND cell, maybe a cell
requesting an application connection to a particular address, etc.),
and if OR_1 can later break the public encryption key of OR_2, then he
can read that traffic. This means that PFS is broken (sortof, there
was never really traffic sent that was readible by OR_2 anyway).  So,
it looks like there is a break on a desirable property that we thought
we had. These theoretical breaks leave open the possibility of a later
practical break.

If we authenticate the g^y, the problem goes away, yes? Roger noted
that signatures doubles the size. We can send a key with the g^x
which can be used to MAC the g^y. This should keep things neat and
small, but we should probably think more if it is adequate.

aloha,
Paul