Notes from the prop224 proposal reading group
Hello, so we had a meeting about the future of "Next Generation Hidden Services" aka prop224. It was a good meeting. We spent most of the time discussing the topics brought up here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html Please read the above mail to get up to speed with the topics of discussion. So these are basically two topics: a) Should we try to maintain backwards compatibility with old intro/rend points? We ended up deciding that it's actually worthwhile keeping backwards compatibility if we can help it: Our rationale was that coding the logic for the extra cells that are required to maintain backwards compatibility is probably less painful than coordinating a perfect bug-free incremental deployment of prop224 in such a way that the whole network has upgraded before we enable client support. So our current plan is to bake backwards compat in the code, and also introduce a consensus parameter of "Should we connect to prop224 onion services using legacy IPs/RPs?" which we will switch off when a good percentage of the network has upgraded to support prop224. At that point, we will be able to rip out the backwards compat code as well. As an added point to that, we should implement the backwards compat code in a way that it's not spagghetied with the normal code, so that it's easy to analyze and remove when needed. Furthermore, we should look back in prop224 and see if we can simplify the backwards compat logic even more. FWIW, prop224 does not have backwards compatibility for HSDirs, so we will still have to do careful deployment there, and make sure that a good percentage of HSDirs have upgraded to prop224 before we start using them (maybe a new consensus parameter is needed here). b) In prop224, why do intro points need to know the "intro point encryption key" and also what's the point of UPDATE-KEYS-SUBCMD? Nick told us that the main point of UPDATE-KEYS-SUBCMD is that so hidden services can rotate their intro point encryption key periodically, so that they can reset their replay caches. That's a fair point. The big question here is, is this worth the complexity that MAINT_INTRO and UPDATE-KEYS-SUBCMD add to the protocol logic? Unfortunately we don't know the answer to this yet, because we actually don't have stats on how our replay caches are doing currently. Here are some things we need to look into: i) Speak with facebook or some other big onion hoster, and try to get some information about their replay cache. Is it ready to bust? How much space is it occupying? ii) The above will help us gauge replay caches in terms of normal activity, but we also need to think of how replay caches should act in cases of a DoS. iii) Also think about INTRODUCE1 replay attacks in general, and understand how dangerous they can be, so that we know how robust our replay caches should be. Is it _that_ dangerous if an attacker manages to sneak in a replay attack every once in a while? For example, imagine an attacker who fills up our replay cache on purpose, so that she can sneak in one replay attack when we reset it. If an attacker can send legit INTRODUCE2 cells to fill up our replay cache, what does she need the replays for? What other types of attacker are there? After we learn more about the above, we will understand *how much we care* about onion services being able to rotate intro pint encryption keys on the fly using UPDATE-KEYS-SUBCMD. Here are some possible scenarios here: - We end up deciding that INTRODUCE1 replay attacks are *dangerous* and we need to seriously defend ourselves against them. In this case, having some sort of UPDATE-KEYS-SUBCMD mechanism sort of makes sense, since onion services should be able to rotate keys at will and let their clients know, without them having to fetch a new HS descriptor. - We end up deciding that INTRODUCE1 are a concern but not something we should complicate our design considerably for. In this case, we might want to consider improving the quality of our replay caches, by using more compact designs (= more space for entries), or by using bloom filters or a similar tech. A proposal will need to be made if so. Yawning posted the following relevant paper: https://home.kookmin.ac.kr/~mkyoon/publications/2010TKDE.pdf - We end up deciding it's no big deal if the attacker sneaks in a replay attack every once in a while. In this case, we can just go with the most minimal approach and ditch the UPDATE-KEYS-SUBCMD mechanism for now, and have intro points be oblivious about encryption keys (which further simplifies our cell formats, etc.). If we take this approach, and in the future future we change our minds about the importance of replay attacks, we can still add some sort of UPDATE-KEYS-SUBCMD mechanism using the extensions mechanism of ESTABLISH_INTRO cells. Furthermore on this topic, we discussed some alternate approaches for doing replay detection that would require less heavy replay caches: i) Maybe we can have an increasing counter in the HS descriptor, that clients need to also include in their INTRODUCE1 cell. If an onion service receives an INTRODUCE1 cell with a counter value different than the one in the descriptor, it ignores it. Onion services update the counter and publish a new descriptor when their replay cache is close to getting filled. I believe various subtle engineering details are hidden in this scheme, along with edge cases and race conditions like "What happens if the client fetches a descriptor with counter value N, right before the onion service updates the descriptor with a new counter value?". ii) When an intro point replay cache is almost full, the onion service will make new encryption keys, tear down the old intro circuit and make a new one, and also pass a signed "HS moved to another circuit" message to the intro point. The intro point will forward that message to any clients that ask for the onion service using its old keys, so that clients know the right place to ask. Lots of engineering details hidden in this proposal as well. In the end we decided that Roger might have some useful feedback for us here :] More research is required! Cheers!
George Kadianakis <desnacked@riseup.net> writes:
[ text/plain ] Hello,
so we had a meeting about the future of "Next Generation Hidden Services" aka prop224. It was a good meeting.
Also, please see my torspec branch `prop224-fixes` for some torspec changes on prop224. My branch is sitting on top of the prop224 branch of special/dgoulet. You can see it here: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes My branch changes are quite straightforward. The only messy part is the top commit which changes the ntor crypto a bit, because that section was not finished. There were various undefined variables being used from prop216. I introduced the ones missing and now it should be fine™. Stuff I need to look into next: - Can we simplify the backwards compat logic? - Should we add extensions to the rendezvous cells (at the cost of failing backwards compat)? - Address more TODOs (there are a bunch of hard ones in there). - Clean up some messy sections. - Figure out the fate of UPDATE-KEYS-SUBCMD (see my previous mail). Feedback is welcome.
(Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
On Mar 17, 2016, at 7:29 PM, George Kadianakis <desnacked@riseup.net> wrote:
Also, please see my torspec branch `prop224-fixes` for some torspec changes on prop224. My branch is sitting on top of the prop224 branch of special/dgoulet.
You can see it here: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes
Some trivial comments (reading from 1dd4bff6): dcb5e79e649c35ee2379ba38f112ddbd3b117362 + status back to the hidden service host with an empty INTRO_ESTABLISHED + cell. The INTRO_ESTABLISHED cell has the following contents: Strike “empty” aced690def0867597b180e817e57ebd14f64703f Removing the key length field excludes parsing cells containing unknown key types. I can’t see that being a problem for any of the cells where this is used, though - they’d fail on unknown key types anyway. Should be ok I guess. 9d79d6ad76b6126cd3616bfdec10b14a413d9d02 + The PROTOID for this variant is "hidden-service-ntor-curve25519-sha256-1”. We are not using sha256 here anymore. 442f0b3791797ebbac3feb2bffb87318fe8d84 "Clarify prop224 use of shared random” Seems like we will need a lot more detail on how the shared random values are used for the hash ring, the process for switching to the new SRV, and so on. Is somebody planning to write that up? Has it all been decided yet?
Stuff I need to look into next: - Can we simplify the backwards compat logic? - Should we add extensions to the rendezvous cells (at the cost of failing backwards compat)? - Address more TODOs (there are a bunch of hard ones in there). - Clean up some messy sections. - Figure out the fate of UPDATE-KEYS-SUBCMD (see my previous mail).
Happy to discuss any of these any time. My list right now is: - Look at onion hostnames, figure out the extra 4 bits and potentially a checksum - Fix client authentication - Thinking more about denial of service, especially on hsdirs Cheers, - special
John Brooks <john.brooks@dereferenced.net> writes:
[ text/plain ] (Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
On Mar 17, 2016, at 7:29 PM, George Kadianakis <desnacked@riseup.net> wrote:
Also, please see my torspec branch `prop224-fixes` for some torspec changes on prop224. My branch is sitting on top of the prop224 branch of special/dgoulet.
You can see it here: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes
Some trivial comments (reading from 1dd4bff6):
dcb5e79e649c35ee2379ba38f112ddbd3b117362
+ status back to the hidden service host with an empty INTRO_ESTABLISHED + cell. The INTRO_ESTABLISHED cell has the following contents:
Strike “empty”
aced690def0867597b180e817e57ebd14f64703f
Removing the key length field excludes parsing cells containing unknown key types. I can’t see that being a problem for any of the cells where this is used, though - they’d fail on unknown key types anyway. Should be ok I guess.
9d79d6ad76b6126cd3616bfdec10b14a413d9d02
+ The PROTOID for this variant is "hidden-service-ntor-curve25519-sha256-1”.
We are not using sha256 here anymore.
OK I addressed the comments above in my branch `prop224-fixes`. I also ripped out the MAINT_INTRO command as was discussed. Please see: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes (I didn't change the key type thing you pointed out. Not sure if changing it to the old type / len / key architecture would make things better. Please let me know if you decide it will.)
442f0b3791797ebbac3feb2bffb87318fe8d84 "Clarify prop224 use of shared random”
Seems like we will need a lot more detail on how the shared random values are used for the hash ring, the process for switching to the new SRV, and so on. Is somebody planning to write that up? Has it all been decided yet?
Agreed. Looking at the time period logic is next on my stack, and my plan is to make another thread similar to this one.
Stuff I need to look into next: - Can we simplify the backwards compat logic? - Should we add extensions to the rendezvous cells (at the cost of failing backwards compat)? - Address more TODOs (there are a bunch of hard ones in there). - Clean up some messy sections. - Figure out the fate of UPDATE-KEYS-SUBCMD (see my previous mail).
Happy to discuss any of these any time. My list right now is:
- Look at onion hostnames, figure out the extra 4 bits and potentially a checksum - Fix client authentication - Thinking more about denial of service, especially on hsdirs
Sounds good. Let me know when you have thoughts or patches.
On 04 Apr (13:07:29), George Kadianakis wrote:
John Brooks <john.brooks@dereferenced.net> writes:
[ text/plain ] (Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
On Mar 17, 2016, at 7:29 PM, George Kadianakis <desnacked@riseup.net> wrote:
Also, please see my torspec branch `prop224-fixes` for some torspec changes on prop224. My branch is sitting on top of the prop224 branch of special/dgoulet.
You can see it here: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes
Some trivial comments (reading from 1dd4bff6):
dcb5e79e649c35ee2379ba38f112ddbd3b117362
+ status back to the hidden service host with an empty INTRO_ESTABLISHED + cell. The INTRO_ESTABLISHED cell has the following contents:
Strike “empty”
aced690def0867597b180e817e57ebd14f64703f
Removing the key length field excludes parsing cells containing unknown key types. I can’t see that being a problem for any of the cells where this is used, though - they’d fail on unknown key types anyway. Should be ok I guess.
9d79d6ad76b6126cd3616bfdec10b14a413d9d02
+ The PROTOID for this variant is "hidden-service-ntor-curve25519-sha256-1”.
We are not using sha256 here anymore.
OK I addressed the comments above in my branch `prop224-fixes`. I also ripped out the MAINT_INTRO command as was discussed.
Please see: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes
(I didn't change the key type thing you pointed out. Not sure if changing it to the old type / len / key architecture would make things better. Please let me know if you decide it will.)
442f0b3791797ebbac3feb2bffb87318fe8d84 "Clarify prop224 use of shared random”
Seems like we will need a lot more detail on how the shared random values are used for the hash ring, the process for switching to the new SRV, and so on. Is somebody planning to write that up? Has it all been decided yet?
Agreed. Looking at the time period logic is next on my stack, and my plan is to make another thread similar to this one.
Stuff I need to look into next: - Can we simplify the backwards compat logic? - Should we add extensions to the rendezvous cells (at the cost of failing backwards compat)? - Address more TODOs (there are a bunch of hard ones in there). - Clean up some messy sections. - Figure out the fate of UPDATE-KEYS-SUBCMD (see my previous mail).
Happy to discuss any of these any time. My list right now is:
- Look at onion hostnames, figure out the extra 4 bits and potentially a checksum - Fix client authentication - Thinking more about denial of service, especially on hsdirs
Sounds good. Let me know when you have thoughts or patches.
I'm happy with the current changes! I say you can merge them upstream in torspec or wait for a nickm/roger ack :) Cheers! David
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
David Goulet <dgoulet@ev0ke.net> writes:
[ text/plain ] On 04 Apr (13:07:29), George Kadianakis wrote:
John Brooks <john.brooks@dereferenced.net> writes:
[ text/plain ] (Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
<snip>
OK I addressed the comments above in my branch `prop224-fixes`. I also ripped out the MAINT_INTRO command as was discussed.
Please see: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-fixes
(I didn't change the key type thing you pointed out. Not sure if changing it to the old type / len / key architecture would make things better. Please let me know if you decide it will.)
442f0b3791797ebbac3feb2bffb87318fe8d84 "Clarify prop224 use of shared random”
Seems like we will need a lot more detail on how the shared random values are used for the hash ring, the process for switching to the new SRV, and so on. Is somebody planning to write that up? Has it all been decided yet?
Agreed. Looking at the time period logic is next on my stack, and my plan is to make another thread similar to this one.
Stuff I need to look into next: - Can we simplify the backwards compat logic? - Should we add extensions to the rendezvous cells (at the cost of failing backwards compat)? - Address more TODOs (there are a bunch of hard ones in there). - Clean up some messy sections. - Figure out the fate of UPDATE-KEYS-SUBCMD (see my previous mail).
Happy to discuss any of these any time. My list right now is:
- Look at onion hostnames, figure out the extra 4 bits and potentially a checksum - Fix client authentication - Thinking more about denial of service, especially on hsdirs
Sounds good. Let me know when you have thoughts or patches.
I'm happy with the current changes! I say you can merge them upstream in torspec or wait for a nickm/roger ack :)
OK, I merged the spec changes from this thread upstream. They should be on the HEAD of https://gitweb.torproject.org/torspec.git . Thanks for the feedback!
George Kadianakis <desnacked@riseup.net> writes:
[ text/plain ] Hello,
so we had a meeting about the future of "Next Generation Hidden Services" aka prop224. It was a good meeting.
We spent most of the time discussing the topics brought up here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html Please read the above mail to get up to speed with the topics of discussion.
<snip>
b) In prop224, why do intro points need to know the "intro point encryption key" and also what's the point of UPDATE-KEYS-SUBCMD?
Nick told us that the main point of UPDATE-KEYS-SUBCMD is that so hidden services can rotate their intro point encryption key periodically, so that they can reset their replay caches.
That's a fair point. The big question here is, is this worth the complexity that MAINT_INTRO and UPDATE-KEYS-SUBCMD add to the protocol logic?
Unfortunately we don't know the answer to this yet, because we actually don't have stats on how our replay caches are doing currently. Here are some things we need to look into:
i) Speak with facebook or some other big onion hoster, and try to get some information about their replay cache. Is it ready to bust? How much space is it occupying?
ii) The above will help us gauge replay caches in terms of normal activity, but we also need to think of how replay caches should act in cases of a DoS.
iii) Also think about INTRODUCE1 replay attacks in general, and understand how dangerous they can be, so that we know how robust our replay caches should be. Is it _that_ dangerous if an attacker manages to sneak in a replay attack every once in a while?
For example, imagine an attacker who fills up our replay cache on purpose, so that she can sneak in one replay attack when we reset it. If an attacker can send legit INTRODUCE2 cells to fill up our replay cache, what does she need the replays for? What other types of attacker are there?
After we learn more about the above, we will understand *how much we care* about onion services being able to rotate intro pint encryption keys on the fly using UPDATE-KEYS-SUBCMD. Here are some possible scenarios here:
- We end up deciding that INTRODUCE1 replay attacks are *dangerous* and we need to seriously defend ourselves against them. In this case, having some sort of UPDATE-KEYS-SUBCMD mechanism sort of makes sense, since onion services should be able to rotate keys at will and let their clients know, without them having to fetch a new HS descriptor.
- We end up deciding that INTRODUCE1 are a concern but not something we should complicate our design considerably for. In this case, we might want to consider improving the quality of our replay caches, by using more compact designs (= more space for entries), or by using bloom filters or a similar tech. A proposal will need to be made if so. Yawning posted the following relevant paper: https://home.kookmin.ac.kr/~mkyoon/publications/2010TKDE.pdf
- We end up deciding it's no big deal if the attacker sneaks in a replay attack every once in a while. In this case, we can just go with the most minimal approach and ditch the UPDATE-KEYS-SUBCMD mechanism for now, and have intro points be oblivious about encryption keys (which further simplifies our cell formats, etc.). If we take this approach, and in the future future we change our minds about the importance of replay attacks, we can still add some sort of UPDATE-KEYS-SUBCMD mechanism using the extensions mechanism of ESTABLISH_INTRO cells.
Hm. Unfortunately I didn't receive any feedback on this matter, and we need to move forward here, so I thought about this some more on my own. I'm still not sure what's the right thing to do here, but here are my current thoughts: 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. If UPDATE-KEYS-SUBCMD is implemented, then the intro point will pass the new keys to the client, and the client will be able to connect to the HS by issuing a new INTRODUCE1 cell. On the other hand, if we don't implement the UPDATE-KEYS-SUBCMD mechanism, then the client will need to send an INTRODUCE1 cell to another intro point. 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? So basically, UPDATE-KEYS-SUBCMD does not offer much, except in the case of a targetted DoS. This DoS attack does not seem very plausible to me, since its only purpose is to delay clients. I don't see how it can completely block access to an HS, except if the attacker is able to *instantly* exhaust the replay cache of an HS which should not be the case. 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) Now, if I'm wrong and this hypothetical DoS attack ever becomes a real problem, we can then implement a feature like UPDATE-KEYS-SUBCMD by using the extension fields of ESTABLISH_INTRO and INTRODUCE_ACK. I feel that using extension fields is cleaner than the way UPDATE-KEYS-SUBCMD is currently specified (as a weird subtype of ESTABLISH_INTRO). What do you people think? Do you feel this suggestion is too sloppy? I'm really not sure myself. PS: FWIW, if we are actually serious about INTRODUCE1 replay attacks and we want to block them no matter what, we need to either change our detection method from replay caches to something else, or at least make replay caches more compact so that they fit more elements.
On 24 Mar (16:55:57), George Kadianakis wrote:
George Kadianakis <desnacked@riseup.net> writes:
[ text/plain ] Hello,
so we had a meeting about the future of "Next Generation Hidden Services" aka prop224. It was a good meeting.
We spent most of the time discussing the topics brought up here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html Please read the above mail to get up to speed with the topics of discussion.
<snip>
b) In prop224, why do intro points need to know the "intro point encryption key" and also what's the point of UPDATE-KEYS-SUBCMD?
Nick told us that the main point of UPDATE-KEYS-SUBCMD is that so hidden services can rotate their intro point encryption key periodically, so that they can reset their replay caches.
That's a fair point. The big question here is, is this worth the complexity that MAINT_INTRO and UPDATE-KEYS-SUBCMD add to the protocol logic?
Unfortunately we don't know the answer to this yet, because we actually don't have stats on how our replay caches are doing currently. Here are some things we need to look into:
i) Speak with facebook or some other big onion hoster, and try to get some information about their replay cache. Is it ready to bust? How much space is it occupying?
ii) The above will help us gauge replay caches in terms of normal activity, but we also need to think of how replay caches should act in cases of a DoS.
iii) Also think about INTRODUCE1 replay attacks in general, and understand how dangerous they can be, so that we know how robust our replay caches should be. Is it _that_ dangerous if an attacker manages to sneak in a replay attack every once in a while?
For example, imagine an attacker who fills up our replay cache on purpose, so that she can sneak in one replay attack when we reset it. If an attacker can send legit INTRODUCE2 cells to fill up our replay cache, what does she need the replays for? What other types of attacker are there?
After we learn more about the above, we will understand *how much we care* about onion services being able to rotate intro pint encryption keys on the fly using UPDATE-KEYS-SUBCMD. Here are some possible scenarios here:
- We end up deciding that INTRODUCE1 replay attacks are *dangerous* and we need to seriously defend ourselves against them. In this case, having some sort of UPDATE-KEYS-SUBCMD mechanism sort of makes sense, since onion services should be able to rotate keys at will and let their clients know, without them having to fetch a new HS descriptor.
- We end up deciding that INTRODUCE1 are a concern but not something we should complicate our design considerably for. In this case, we might want to consider improving the quality of our replay caches, by using more compact designs (= more space for entries), or by using bloom filters or a similar tech. A proposal will need to be made if so. Yawning posted the following relevant paper: https://home.kookmin.ac.kr/~mkyoon/publications/2010TKDE.pdf
- We end up deciding it's no big deal if the attacker sneaks in a replay attack every once in a while. In this case, we can just go with the most minimal approach and ditch the UPDATE-KEYS-SUBCMD mechanism for now, and have intro points be oblivious about encryption keys (which further simplifies our cell formats, etc.). If we take this approach, and in the future future we change our minds about the importance of replay attacks, we can still add some sort of UPDATE-KEYS-SUBCMD mechanism using the extensions mechanism of ESTABLISH_INTRO cells.
Hm. Unfortunately I didn't receive any feedback on this matter, and we need to move forward here, so I thought about this some more on my own. I'm still not sure what's the right thing to do here, but here are my current thoughts:
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. Furthermore, the client connection to an IP is _short_ live so when a service needs to rotate the replay cache, we can create a new one for the new keys and the old one can be kept for "on going" introduction with clients and then once they are all done, we can drop that replay cache along with encryption keys. In other words, there are ways that we can address this issue without an update keys subcmd. I don't see the performance benefit.
If UPDATE-KEYS-SUBCMD is implemented, then the intro point will pass the new keys to the client, and the client will be able to connect to the HS by issuing a new INTRODUCE1 cell.
On the other hand, if we don't implement the UPDATE-KEYS-SUBCMD mechanism, then the client will need to send an INTRODUCE1 cell to another intro point.
I think, we could be able to keep the old enc keys for current client introducing themselves as we are rotating our replay cache. This is just a timing issue here between changing keys and serving current clients no?
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....
So basically, UPDATE-KEYS-SUBCMD does not offer much, except in the case of a targetted DoS. This DoS attack does not seem very plausible to me, since its only purpose is to delay clients. I don't see how it can completely block access to an HS, except if the attacker is able to *instantly* exhaust the replay cache of an HS which should not be the case.
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)
Now, if I'm wrong and this hypothetical DoS attack ever becomes a real problem, we can then implement a feature like UPDATE-KEYS-SUBCMD by using the extension fields of ESTABLISH_INTRO and INTRODUCE_ACK. I feel that using extension fields is cleaner than the way UPDATE-KEYS-SUBCMD is currently specified (as a weird subtype of ESTABLISH_INTRO).
What do you people think? Do you feel this suggestion is too sloppy? I'm really not sure myself.
My take on that is we don't need this extra complexity for something we can cope with imo farily easily. And as you say, we can extend at some point the establish intro cell if we discover we _really_ need this. Cheers! David
PS: FWIW, if we are actually serious about INTRODUCE1 replay attacks and we want to block them no matter what, we need to either change our detection method from replay caches to something else, or at least make replay caches more compact so that they fit more elements.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 29 Mar 2016, at 01:44, David Goulet <dgoulet@ev0ke.net> wrote:
On 24 Mar (16:55:57), George Kadianakis wrote:
George Kadianakis <desnacked@riseup.net> writes:
[ text/plain ] Hello,
so we had a meeting about the future of "Next Generation Hidden Services" aka prop224. It was a good meeting.
We spent most of the time discussing the topics brought up here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html Please read the above mail to get up to speed with the topics of discussion.
<snip>
b) In prop224, why do intro points need to know the "intro point encryption key" and also what's the point of UPDATE-KEYS-SUBCMD?
Nick told us that the main point of UPDATE-KEYS-SUBCMD is that so hidden services can rotate their intro point encryption key periodically, so that they can reset their replay caches.
That's a fair point. The big question here is, is this worth the complexity that MAINT_INTRO and UPDATE-KEYS-SUBCMD add to the protocol logic?
I'm not convinced that this feature is necessary. I think we should remove it, and if it looks like it's needed later, we can write a separate, small proposal for it that gives reasons why it's needed. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Mar 28, 2016, at 9:44 PM, David Goulet <dgoulet@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
participants (4)
-
David Goulet -
George Kadianakis -
John Brooks -
Tim Wilson-Brown - teor