Open, hosted federation using DomainKeys Identified Federation (DKIF) Hi Guys, We are working on a project which extends the current stellar federation standard/workflow in order to improve security and enable hosted federation without the need to trust the federation provider. The extension is based on a simplified version of the well known and used standard DKIM (DomainKeys Identified Mail) . It introduces signing of federation records and signature validation by the client. The solution is backwards compatible with the current workflow. Older clients can simply ignore the signature and newer clients which implement the new validation workflow can show a sign to the sender to verify that DKIF was used to resolve the federation andress. Using this extension we would like to introduce a donation based, secure and open stellar federation service for Stellar community individuals and a hosted federation service for users and organizations who have their own domain but cannot, or do not want to, host their own federation server. As this proposal would require a minor modification/extension of the current federation workflow, we would be very keen to hear the feedback of the Stellar developers together with the community members. Current federation workflow Currently, in order to resolve a federation address, the client needs to do the following: 1) fetch the stellar.toml file from https://<domain>/.well-known/stellar.toml and read the FEDERATION_SERVER entry from it 2) fetch the response from the federation server using secure HTTP GET and required parameters 3) proceed with the payment Although it is mandatory to use HTTPS for both requests, both the web server and the federation server are possible targets for hackers. These servers are directly exposed to the internet and if a hacker manages to compromise either of them they could redirect the payments. In case an attacker compromised the web server hosting the example.com site, they could rewrite the stellar.toml file pointing the FREDERATION_SERVER entry to their own host, serving wrong records and receiving all the payments. Compromising the federation server would allow the attacker to replace the public keys in each response, receiving all the payments. Proposal: signing and validating the federation records We would like to introduce the signing of the federation records using the workflow below. These signatures can be inspected and validated by the clients (“wallets” who are sending money to a destination address) before sending payments. Preparation We generate a domain signing key pair using Ed25519 (same algorithm that is used for other components ) for each domain. We keep the public key in a TXT record (same method as DKIM) in the DNS of the domain which looks like the following: federation._stellardomainkey IN TXT “<publickey>” . The format of the public key matches exactly the format of a Stellar address, and the existing tools for creating a signing pair can be used. We pre-sign the federation records (offline) and include the signatures into the DB together with the other entries. We will have one signature per federation entry which contains all the federation records (stellar_address, account_id, memo_type, memo). We configure the federation server to include a signature entry into the JSON response which looks like the following (see DKIM for more info about fields): “signature”:”<base64signature>” Workflow with the new clients New clients that support DKIF would take the following steps to resolve a federation address and validate it’s signature: 1) fetch the stellar.toml file from https://<domain>/.well-known/stellar.toml and read the FEDERATION_SERVER entry from it 2) fetch the response from the federation server using HTTP GET and required parameters 3) try to fetch the public key from the federation._stellardomainkey.<domain> TXT record of the domain 4) If both of the public key and the signature from the federation response were missing then client proceeds with the payment without DKIF validation as it currently does 5) If only one of them was missing (public key or the signature in the federation response), it blocks the payment and warns the sender 6) If both public key and signature were found, but federation entries cannot be validated using the signature and the public key, it blocks the payment and warns the sender 7) If federation entries could be validated using the signature and the public key it proceeds with payment (and notes the sender that the resolution was using DKIF) This workflow is compatible with existing clients and federation servers which do not implement signing/validation. Older federation servers would not return a signature field and older clients would just ignore the signatures (we assume that clients ignore additional fields in the JSON response from federation servers). Benefits When a federation service is using DKIF, taking over the web server which hosts the stellar.toml file and/or the federation server itself would not allow the attackers to redirect the payment. In order to do that, they would need to alter in addition the DNS response on the client side as well. This allows (and requires) that the open federation providers sign the records offline and upload it to the federation database together with the records. It also allows the introduction of federation hosting for people or organisations who have their own domains but do not want or cannot run their own federation server. These people can include their public key into their own DNS, sign the records with their private key, upload them together with the signatures to a federation hosting provider and point the FEDERATION_SERVER entry to the provider. With this solution there is no need to trust the federation provider as it would not be able to temper with the presigned records or signature. UPDATE: we are live! Finally, we went live with our Secure Open & Hosted Stellar Federation service. The site is here: https://lumenbox.org Please enjoy and provide your feedback. ?

This idea sounds cool. I have a vague understanding of it. I think your post could use a concrete example though. I know I would have a much clearer picture of the proposal if I had a concrete example to chew on.

Cajga Love the idea! Taking over a federation server and returning a malicious addresses is currently a possible attack vector. This solution is simple, effective and also backwards compatible . ? I was first a bit concerned about the offline signing part and how you could handle inserting the records into the DB, but after thinking about it more I think you can automatise it and don't see it as a big problem now. Another possible attack vector around federation is inserting similar addresses and counting on users making a mistake and misspelling it. Maybe to prevent it you could disallow addresses that are only 1 letter different. Great work!

Cajga Very great! Much needed ?

Interesting, although it's one more private key to hold and secure for the user. Edit: actually, we could recommend the user use https://keybase.io which makes it easier to manage this, at least for private parties. I'll see if I can implement this in https://stellarid.io

Cajga Could you flesh out a more detailed spec for this? Specifically: How to generate a key pair (openssh? what are the parameters?) How to sign a message with the private key What the message should be (I'm guessing stellar_address:account_id:memo_type:memo )

Our open and hosted federation service will go live in few days using DKIF. When this happens, we will open source all of our git repos which apart from some tools and containers includes libraries for signing and validating the signatures. You will be able to use the libraries in your service. Our aim is to have good libs (PRs) and tools built as well as release a detailed technical documentation so, multiple services (wallets, federation servers/sites ) can adopt it easily which will hopefully lead to SDF changing the standard. We shall see if this happens ? @frejete We will announce it here so stay tuned. ?

Cajga https://github.com/stellar/stellar-protocol Write a proposal, and add it here

I like the idea, and I agree there must be a way to verify the records. One quick question, why store the key in a TXT record over storing it in stellar.toml?

fracek I thought the same thing at first, but after thinking a bit more it makes sense: if you hold the public key on the stellar.toml file, then it's a single point of failure. If someone obtains write access to your web server they can re-write the stellar.toml file to point to another federation server and omit the DKIF key. If the DKIF is decoupled from the file and on the DNS, you'd need access to both the DNS and either the federation server or the stellar.toml to hijack an address.

dzham Thank for the link. We overlooked it till now :/ We would have started there. We will write the proposal frejete That is the exact reason. One would need to have control on both the client and the federation side in order to alter the address for the payment in our proposal

DomainKeys Identified Federation (DKIF)

frejete

MisterTicot Also the Stellar protocol explicitly says you should not cache Federation responses. https://www.stellar.org/developers/guides/concepts/federation.html#caching

MisterTicot

frejete
Thank you for bringing this to my attention.
It would be nice having thoses federation servers adding a no-cache clause to their reply.

frejete

MisterTicot Good point, I will do that for StellarID.io

MisterTicot

@Cajga

Your federation server returns an empty string as memo when no memo is set.

I don't know if it's legit or not. I would rather expect no memo field at all, like StellarId does.

Cajga

@MisterTicot thanks for the report.

Let me have a look and get back to you.

Cajga

@MisterTicot

So, even if I kind of agree with you on this, please note that the official federation server behaves in this way. Here is how I tested it:

$ go get -u github.com/stellar/go/services/federation
$ cat federation.cfg 
port = 8000

[database]
type = "postgres"
dsn = "postgres://localhost/federation_sample?sslmode=disable"

[queries]
federation = "SELECT id FROM people WHERE name = ? AND domain = ?"
reverse-federation = "SELECT name, domain FROM people WHERE id = ?"

[tls]
certificate-file = "/tmp/localhost.crt"
private-key-file = "/tmp/localhost.key"
$ ./federation --conf federation.cfg &
$ psql -U postgres federation_sample
psql (9.2.23)
Type "help" for help.

federation_sample=# \pset null '(null)'
Null display is "(null)".
federation_sample=# 
federation_sample=# select * from "people" where name='szil2' or name='sig';
                            id                            | name  |   domain    |  signature  | signature_rev |  memo  | memo_type 
----------------------------------------------------------+-------+-------------+-------------+---------------+--------+-----------
 GD2GJPL3UOK5LX7TWXOACK2ZPWPFSLBNKL3GTGH6BLBNISK4BGWMFBBC | szil2 | stellar.org |             |               |        | 
 GA2GJPL3UOK5LX7TWXOACK2ZPWPFSLBNKL3GTGH6BLBNISK4BGWMFBBC | sig   | stellar.org | test        |               | (null) | (null)
(2 rows)

federation_sample=# \q
$ curl -k 'https://localhost:8000/federation?q=szil2*stellar.org&type=name'
{"account_id":"GD2GJPL3UOK5LX7TWXOACK2ZPWPFSLBNKL3GTGH6BLBNISK4BGWMFBBC","memo":""}

We patched (and submitted a pull request to) the official federation server to support DKIF and we are using this version for our federation service.
We could open an issue (I had a look but could not find one) to the official federation server about this and see why did they decide to return an empty valued memo field in the json and I am happy to follow what they decide.

MisterTicot

Cajga

Hm I kind of expected this. Well, that would be nice to know.

Thank you for this complete answer.

MisterTicot

Cajga
I still wonder. Do you know why in the DB in your example szil2 have an empty memo field while sig have a (null) memo field ? Wouldn't then be (null) value the right one ?

I'm not sure if I get it right.

AlexanderLeon

I'd like to integrate lumenbox into something I'm building. Would it be possible for you to enable CORS on the https://lumenbox.org/verify path?

MisterTicot

@Cajga I'm running into a problem trying to implement DKIF support into cosmic-lib. Client-side JavaScript seems to have no way to get TXT records information. A solution could be using one of the API (third-party) available. I wonder if we can find a way to store the public key that would.allow for a direct fetch from client side application.

Cajga

@MisterTicot Yes, we thought about this limitation (problem with "pure client-based" application) and actually did a lot of research back when we designed the protocol but could not find a very good solution for it.
The thing is that DNS is the best place to store your public key as this reduces the possible attack vectors of the system (in case the attacker can modify your DNS records, you are done anyhow).

Some big players realized this issue long ago and started to offer DNS-over-HTTPS interface and as you said probably this is the best what you can do when you do not have any server side component (which could do the lookup for your client):
cloudflare
google

One more solution could be that this lookup gets integrated into horizon but how the things are moving currently (we've never received any comment on our PRs or SEP) I do not think this will ever happen.

MisterTicot

Cajga Thank you for this precise answer. I will go this way then.

« Previous Page