Changes between Version 13 and Version 14 of Ticket #25882, comment 32


Ignore:
Timestamp:
Aug 25, 2018, 2:55:40 PM (10 months ago)
Author:
cypherpunks2
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #25882, comment 32

    v13 v14  
    77
    88> Doing that will rule out the above malicious case (which does not seem very useful from an adversary PoV), and also help us debug bugs like this. However, it will not help with issues like the outgoing rendezvous circuit timing out or failing on the service-side (probably what's happening here), and it will also slightly delay ''all'' rendezvous circuit setups because the ACK has to be end-to-end.
     9
     10A small correction to your last sentence: the problem is not that the rendezvous circuit is failing on the service-side, but that the intro circuit is failing.
    911
    1012It is a useful attack if the adversary wants to degrade the performance of onion services network-wide by making them inaccessible from clients that would otherwise need to re-fetch the descriptor for onion services.  If a client extends to a buggy or malicious intro point of the type described here, then it will not re-fetch the descriptor, or at least not until its time-based expiration, since from its perspective at least one intro point is still working.  Considering that the need to re-fetch the descriptor prior to its time-based expiration is a necessary and expected part of normal operation for a client, the ability for an intro point to behave this way constitutes:
     
    1719
    1820Also, it is not true that the only possible fix is to have the client wait for the end-to-end ACK from the service.  The intro point could deliver two (2) ACK messages, the first being the one that is currently given and the second being the end-to-end ACK that you describe.  After receiving the first ACK, the client could reach out to the rendezvous point optimistically, and then if it does not hear the second ACK (i.e. the one from the service via the intro point) within a particular period of time, then it would mark the intro point as unreachable, toward re-fetching the descriptor for the service.  That is the essence of [comment:20 Proposal A] and ultimately my recommendation for a long-term solution.
    19 
    20 Also, a small correction to your last sentence: the problem is not that the rendezvous circuit is failing on the service-side, but that the intro circuit is failing.