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 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 )

DomainKeys Identified Federation (DKIF)

MisterTicot

Cajga
Very great!
Much needed ?

frejete

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

frejete

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)

Cajga

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. ?

dzham

Cajga

https://github.com/stellar/stellar-protocol

Write a proposal, and add it here

Cajga

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

Cajga

dzham

We wrote proposal pretty long time ago but did not get feedback from Stellar DEVs.
We created a site which explains the DKIF in a simple way and put it up to lumenbox: https://lumenbox.org/dkif-explained/

As you can see above, we went live with our service which is using DKIF (obviously, we would need wallets to support it but for this we need the SDF's support): https://lumenbox.org

fracek

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?

frejete

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.

fracek

frejete Good point. My only worry is that requiring a separate library to perform DNS lookup will increase barrier to entry and so people won't implement it. With everything in one place it would be a trivial change.

EDIT: As soon as you have a draft spec, please post it here and I will implement it for my federation function! I agree with you that this is 100% needed.

rbates

I've been following this thread as I think what's being discussed here is really interesting and an important step in increasing the adoption of federation services.

Here's a slightly different approach I wanted to run by you all.

What if the client were to have the user enter/update their federation address into a data field attached to the address? IE, make the key/value standardized like: federation_address:user*domain.com.

Using this approach a wallet could compare the data field on the ledger with the federation response to make sure they matched before sending.

One downside is the base reserve required to create the entry, but if we proved it out maybe we could make the case for it being added as default key similar to Home Domain.

frejete

rbates The thing is, you can have many federation addresses on the same account. For example, an exchange could have a federation address for each user like frejete*binance.com that all fall into the same exchange account but each automatically set the correct memo for the user (imho they should already be doing this seeing the number of people forgetting the memo and the time it must cost them on support tickets). Storing that many data entries would be slow and costly.

rbates

frejete You're right, that's a good point. The use of the memo is a clever way to handle sub-accounts. I can’t however shake the feeling that by taking this approach you end up depending on core, federation, and the app developer to apply logic in isolation. Bring the end user sending a payment into the equation and you now have 4 variables. That’s a lot of moving parts, and if a payment goes awry the ability to diagnose the issue and enforce accountability will be difficult.

rbates

rbates Couple additional thoughts I've been having since I wrote this.

There's really two things being addresses here. One is making sure that the mapping between the federation address and the wallet address can't be easily tampered with. The second is using federation + memo as a mechanism for managing sub accounts.

For the sake of the discussion I think it's worth considering that these could be solved in different ways. For example, if stellar core had the concept of an incremental id attached to each account people could still build their account management solutions off the ledger, but there would be a way to enforce uniqueness and prevent situations where the memo is critical but gets submitted as empty. You wouldn't need to store balances for sub-accounts in the ledger, just have core reject the transaction if it's not in range (ABC, ABC-01, ABC-02).

Circling back to federation, with a setup like this you could require that Stellar accounts and their user aliases were mapped one-to-one without passing around memos from federation to client to core.

Sorry if this is slightly off the original topic of DKIF, I just feel like the security, identity, and technical architecture discussions around all of these are intertwined.

Cajga

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. ?

keksper

Hi @Cajga, this vulnerability should theoretically not exist if you host your own Federation server, correct? It's only if you are relying on a third-party server?

Cajga

Hi keksper

In the current federation workflow if any of the web server or federation server gets compromised the attacker can redirect the payment to his own account. This is independent of who hosts these services.

In case your federation record is hosted by someone else obviously the problem mentioned above is also there but the owner would not even need to overtake the server as he manages it ?

With the DKIF extension, this risk is mitigated as the records are signed and the key for the validation is in the DNS. So in order to redirect the payment, an attacker would need to take over one of the servers AND forge the DNS query/response on the client side.

https://lumenbox.org (thanks to DKIF) allows you to upload your signed federation records for your own domain to our federation database. We will serve it to the world so you do not need to run and maintain a federation server. As the signing is done by you (only you know the secret key that you used for signing) and the DNS is also managed by you for your own domain (so you are the only one who can upload/change the validation key into it) your records cannot be tampered on the federation server side.

Obviously this only works when the clients/wallets are supporting the DKIF extension to verify the signature of the records. Let see if the Stellar DEVs will like the idea and ask everyone to support this.
As the DKIF extension is fully backwards compatible, until this happens, you can register a lumenbox.org Stellar address or use an address for your own domain on https://lumenbox.org. This will work perfectly for the current, standard federation.

MisterTicot

Hi Cajga!
Finally I took the time to read and try to understand the technicals.

Congratulation for the good design job and the nice website. ?

There's only one part I don't get: how do you store the key in the DNS? Is it an option to serve text file directly from your DNS provider?

I'm willing to implement a securing protocol for address resolution into Stellar Authenticator & cosmic-lib. The library would allow other web developpers to use your enhanced resolution protocol without any pain. Cosmic link protocol support federated address by default and as you did explain we need it to be more secure than it actually is. We need it rock-solid! You can guess how happy I am that someone is willing to tackle this issue ?

I'm still wondering about your design. Is it correct than taking over the DNS an attacker could redirect payment? As I understand it, the public key is on the DNS, and the DNS is also the link between user and toml file, is that right?

Cajga

Hi @MisterTicot

Thanks for the congratulation for the site, the points are going the other two members of the team. They developed the site, the app and the underlying API.

The DKIF public key is stored as a TXT record in the DNS. As an example, here is the public key pair of the key that we use for signing at https://lumenbox.org:

$ dig +short -t txt federation._stellardomainkey.lumenbox.org
"GAI55SVFTWSRNRFQGPUD264OF6UDD2O3MGUBDZWFR2GRJ3WOCTFUUMLP"

Your question about DNS server mentions a very important point. Although, DKIF is a significant and very important step towards a secure Stellar Federation protocol (as signing the federation record reduces the attack surface with the federation and the web server), it is not an all-in-one solution which mitigates all the possible attack vectors alone. It is very important to understand that securing the underlying protocols and infrastructure are still required!

Taking over the DNS request/response is a very powerful attack and an attacker has many different possibilities/places to do so. It is extremely difficult to properly protect the name resolution against these.
In case an attacker is able to take over the DNS server which serves your records (or your account at the registrar who registered your domain ? ) then basically he owns your domain. He can simply resolve the records of the domain to his own IP and start to serve the federation responses from his own federation server (some ISP may cache the DNS records so it may take few hours until all the federation requests will be directed to his server) after he got a TLS cert to your domain from one of the automated cert providers which use Domain Validation.
There are some ways to try to prevent this (DNNSEC is probably the best and could delay the real problem a bit but unfortunately apart from other weaknesses, the client resolver must support it otherwise it is useless and it is often not the case!).
These are serious risks but it is more likely that the attacker take over the client itself (like has a software on your PC on which you use your wallet) and just simply get your Stellar Secure Seed when you log in to your wallet or sign a transaction ?

So, all in all, there is no bulletproof solution out there but we should try to improve the security posture with solutions which does not "cost too much".

MisterTicot

Cajga
Thank you for this complete answer, I think I got it all now.

Maybe some caching could secure the process further? Then check against new values. Like if public key and destination both changed since last time, raise an error and ask for explicit user confirmation?

The idea is that in most cases legitimate users would update one or the other at a time; while an attacker likely would change both.

Or did I missed a common usage scenario where you would update both publicKey and account ID?

Edit: hm... Nevermind there's some issues that looks difficult to tackle. Like what if I didn't connect since a month(ignore change?); Or what if my federated server host thousands of address and I want to change my publicKey?

There should be some simple way but I can't catch it.

frejete

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