Approaches for adding authorization?

[blinry]

Hi! I learned about iroh at FOSDEM, and it might solve a real problem for us: Syncing Automerge documents across different local networks in Ethersync!

My question: What approaches do you recommend for adding authorization – making sure that only certain people can exchange data with you? Applications like dumbpipe seem to use only a NodeTicket as an "authorization token" which you need to know to connect. But depending on the enabled discovery mechanisms, isn't it possible that other people could learn about your public key, and then connect to you?

Two ideas:

• Keep a list of trusted public keys. For each new connection, if the peer is not in that list, don't open streams to it/terminate the connection again. What's impractical about this is that two people who want to connect to each other then first have to exchange their public keys in both directions, preventing a simpler usage where you can just give someone a ticket to connect to you.
• Create a passphrase, and add it to the ticket. When receiving a connection, open a stream, and as the very first thing, verify that both parties know the same passphrase using a PAKE algorithm like this one. If the exchange doesn't succeed, abort the connection. I'm not completely confident about the security properties of a solution like that. But it would only require sharing information in one direction.

I think it might be helpful if you wrote a little guide on this topic, because many people who go beyond a certain prototyping stage might ask themselves similar questions.

And some more specific questions:

• In dumbpipe, does keeping the NodeTicket secret actually prevent other people from connecting to the pipe? Would this also be true when DNS or local discovery would be activated? To me, this seems important to mention in the documentation of discovery mechanisms.
• When accepting a connection from an unknown peer, what can they learn about you? Your supported protocols, I assume?
• In iroh-gossip, can people who don't know a Topic somehow learn about it? In other words, is sharing a ticket containing a topic a good way to form private gossip "groups"? Also here, I'd suggest adding this piece of information to the protocol documentation.

Note: The ticket documentation, which mentions "secret document tickets" has two dead links: https://www.iroh.computer/docs/layers/document and https://www.iroh.computer/docs/api/doc-share. And https://www.dumbpipe.dev has a dead link to https://iroh.computer/docs/layers/connections.

Thanks a ton for working on this awesome project! :)

[dignifiedquire]

• In dumbpipe, does keeping the NodeTicket secret actually prevent other people from connecting to the pipe?

In practice yes. The criticial piece of information is the NodeId to connect to a node, think of it like an IP + port number in a world where everyone has a static ip. Now, because there are many more combinations of a NodeId you can't iterate over them easily, like you can do over port numbers, but I would still recommend not reyling on this for actual authentication.

[dignifiedquire]

When accepting a connection from an unknown peer, what can they learn about you? Your supported protocols, I assume?

Roughly

• your public IP addresses
• your supported ALPNs
• connection timings etc

This is the raw iroh level, each protocol on top of course could share different information, depending on what it does

[dignifiedquire]

What approaches do you recommend for adding authorization

I am currently working on a way to add a generic way for simple authentication that can be wrapped around protcols here: #3157

[blinry]

Thanks for the explanations, and very cool that you're working on an authorization wrapper! I have a couple of follow-up questions, as understanding this correctly seems critical for using a library like this:

Confidentiality of NodeIds

The criticial piece of information is the NodeId to connect to a node, think of it like an IP + port number in a world where everyone has a static ip. Now, because there are many more combinations of a NodeId you can't iterate over them easily, like you can do over port numbers.

• Without knowing the NodeId, is it always impossible to establish a connection to a node (say I'm in the same local network, and know its IP and the ports it's using)? That would be a useful security property.
• Which discovery mechanism allow others to learn about your NodeId? I'm assuming the LocalSwarmDiscovery would broadcast it in the local network? How about DNS discovery, Pkarr and DHT?
• In dumbpipe/sendme, could the people who run the DNS servers that are used for discovery connect to the nodes offering a connection? (Because they would learn the node's NodeId, and that's all that's needed to connect?) My mental model of these services would be that the "infrastructure in the middle" can't intercept my files, only the people I trust. But maybe that's not the promise you're making?

Different approaches for adding authorization

• When feat(iroh)!: allow for limiting incoming connections on the router #3157 lands, we could use the positive-listing approach. Do you see a way around having to do the following dance?
  1. A tells B its NodeID (via side channel)
  2. B tells A its NodeID (via side channel)
  3. A adds B to its positive list
  4. B connects to A
• What do you think of the following approach: Create a passphrase, and add it to a ticket, and share it with B. When receiving a connection, open a stream, and as the very first thing, verify that both parties know the same passphrase using a PAKE algorithm like this one. If the exchange doesn't succeed, abort the connection. I'm not completely confident about the security properties of a solution like that. But it would only require sharing information in one direction.
• In iroh-gossip, can people who don't know a Topic somehow learn about it? In other words, is sharing a ticket containing a topic a good way to form private gossip "groups"? That would be a solution with the nice property of only having to share information in one direction, instead of a back-and-forth for positive-listing a NodeId.

Really thankful for your time answering those questions! 💚