DomainKeys Identified Federation (DKIF)

Cajga

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

bkolobara

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!

MisterTicot

Cajga
Very great!
Much needed ?

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)

istrau2

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.

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

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