[tor-dev] Notes from the prop224 proposal reading group

[John Brooks]

> On Mar 28, 2016, at 9:44 PM, David Goulet <dgoulet at ev0ke.net> wrote:
> 
> On 24 Mar (16:55:57), George Kadianakis wrote:
>> 
>> 
>> First of all, the UPDATE-KEYS-SUBCMD mechanism does not actually prevent replay
>> attacks at all. It's a performance feature. It's there so that if the HS
>> rotates its replay cache and encryption key, the intro point can inform clients
>> about the new encryption key. The win here is performance, since that clients
>> don't need to fetch a new descriptor to learn the new encryption key.
>> 
>> Howevr, the performance gain from UPDATE-KEYS-SUBCMD does not seem substantial
>> since it only occurs in the case where a client has already fetched an HS
>> descriptor, and then the HS rotates its keys, and then the client wants to
>> revisit that HS.
> 
> IMO, as I stated in #tor-dev discussions, I don't think this is a lost in
> performance. Fetching a new descriptor is cheap and by cheap I mean it's
> something that the client does once all IPs in there don't work which is (if
> all goes well) once every ~18-24h.

There is a factor other than performance: UPDATE-KEYS-SUBCMD allows the service to
clear the replay cache without rebuilding or moving the introduction circuit.

If we have to tear down the intro circuit when the replay cache is full, an adversary can
force us to build a new circuit to our introduction point with a flood of requests. We should
definitely keep the same introduction point when we’re doing this, or the issue gets worse -
the adversary could repeat this until we pick their sybil as our introduction point.

Even when using the same introduction point, the adversary can force new circuits to insert
their sybil between the service and an introduction point. I’m not sure how useful that is;
probably not very much unless passively watching introduction timing helps in a correlation
attack. Guard discovery would be much more efficient using rendezvous circuits.

If that is a problem, there are still easier ways to solve it. We could allow a new
ESTABLISH_INTRO (with a new auth key) on an established introduction circuit, so the
service could rotate those keys without building a new circuit and without any additional code.
We could also just pin that circuit, and rebuild it through exactly the same relays. These give
the introduction point a way to link the circuits, which I guess could matter for
popularity-hiding..


>> This is not terrible performance-wise. However, in the worst case, where the
>> HS has rotated the encryption keys of *all* its intro points, then the
>> client will need to try all of them, fail all of them, and fetch a new
>> descriptor. This worst case scenario should never really happen, except if
>> the HS is under INTRODUCE1 DoS and rotates its keys more frequently than
>> usual. But why would an attacker do that?  To delay the clients?
> 
> I'm also OK with a client re-fetching the descriptor tbh….

This one doesn’t concern me either. It’s an expensive attack to mount with small
benefit, and there are better ones we haven’t solved yet.

> 
>> 
>> Hence, my current intuition is to kill the UPDATE-KEYS-SUBCMD feature for
>> the sake of simplicity. It seems like a dirty and not trivial to implement
>> feature that so far only helps in the case of a hypothetical DoS attack
>> which is not very profitable (fwiw it's also possible with the current
>> hidden services subsystem)

+1. Let’s do it.

- special

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160330/66acb8ad/attachment.sig>