On 6/2/20 3:01 PM, Nick Mathewson wrote:
On Thu, Apr 23, 2020 at 2:48 PM Matt Traudt pastly@torproject.org wrote:
Hi! I've got some comments on the FlashFlow proposal; I'll start with the ones that I think are most important, so that we can try to get them out of the way.
First off, I'm concerned about the approach where measurers get to consume a certain amount of bandwidth, with only a set fraction left to devote to the background traffic. It seems like a hostile set of measurers could use this authority to introduce traffic patterns on the network to assist in traffic analysis. In general, having regular scheduled and visible changes in relay capacity seem to me like they'd help out traffic analysis a good deal.
Second, the "MSM_BG" information type also seems like a serious traffic analysis risk. It is, literally, telling the measurers a report of how much traffic was sent each second on other connections. Previously we decided that a much coarser summary than this was too much information to publish in bandwidth-history lines, and I'm worried not to see any analysis here.
{In both of the above cases we might say, "well, an attacker could do that anyway!" But to get the traffic information, an attacker would need to compromise the upstream connection, and to introduce traffic spikes the attacker would need to risk detection. This proposal as written would make both of these traffic analysis opportunities an expected part of the infrastructure, which seems not-so-good to me.}
Not just anyone can be a measurer. A bandwidth authority runs a coordinator and chooses to trust some small number of measurers. In practice, knowing the humans behind the dirauths today, I'd expect each would only trust measurers they run themself.
Third, I don't understand why we're using cell crypto here but we aren't using RELAY cells or (apparently?) circuits. Since TLS is already in play, we'll already be measuring the relays' encryption performance. But if we do decide that cell crypto is needed, then it's way easier to get that crypto happening if there are circuits involved. I think there's been some discussion of that on IRC; I'd suggest that we try to make that work if we can.
Yes the outcome of some IRC discussion with asn is that we should start with MSM_ECHO cells being RELAY cells until we discover that is untenable. The proposal will be updated to state this as well as clarify that we'll be building circuits on which to send measurement traffic.
Fourth, this approach to authenticating echo cell contents seems needlessly complicated. Instead of using random contents and remembering a fraction of cells, it would make more sense for measurers to use a keyed pseudorandom stream function to generate the cells, and to verify the contents of all the cells as they come back in. (AES128-CTR and ChaCha8 and SHAKE128 all have nice properties here.)
The motivation here is to do everything possible to prevent measurers from being a bottleneck before the relay, which was a problem for us in prototyping. This final transition-able FlashFlow is starting out with verifying all cells the normal way so we can see if this can of worms is even necessary. I'm not optimistic.
Fifth, using IP addresses for identification is NOT something we do on the production network. I think we should authenticate measurers by identity key, not by IPv4 address (as is happening here, unless I misunderstand.)
It's the short term deployment that we propose use IP addresses for identification. At this point there's 1 FlashFlow deployment being operated by us and measuring relays that have opted in to running our patches (realistically: just us, but hopefully some adventurous operators too). In the medium/long term coords/measurers will use proper TLS identities that will be checked by the relays.
Maybe that's still unacceptable, but I just wanted to make that clear.
Matt